Replace Sema-level implementation of -fassume-sane-operator-new with a
CodeGen-level implementation. Instead of adding an attribute to clang's
FunctionDecl, add the IR attribute directly. This means

Replace Sema-level implementation of -fassume-sane-operator-new with a
CodeGen-level implementation. Instead of adding an attribute to clang's
FunctionDecl, add the IR attribute directly. This means a module built with
this flag is now compatible with code built without it and vice versa.

This change also results in the 'noalias' attribute no longer being added to
calls to operator new in the IR; it's now only added to the declaration. It
also fixes a bug where we failed to add the attribute to the 'nothrow' versions
(because we didn't implicitly declare them, there was no good time to inject a
fake attribute).

llvm-svn: 265728

show more ...

Basic: move CodeGenOptions from Frontend

This is a mechanical move of CodeGenOptions from libFrontend to libBasic. This
fixes the layering violation introduced earlier by threading CodeGenOptions i

Basic: move CodeGenOptions from Frontend

This is a mechanical move of CodeGenOptions from libFrontend to libBasic. This
fixes the layering violation introduced earlier by threading CodeGenOptions into
TargetInfo. It should also fix the modules based self-hosting builds. NFC.

llvm-svn: 265702

show more ...

[CUDA] Add -fcuda-flush-denormals-to-zero.

Summary:
Setting this flag causes all functions are annotated with the
"nvvm-f32ftz" = "true" attribute.

In addition, we annotate the module with "nvvm-re

[CUDA] Add -fcuda-flush-denormals-to-zero.

Summary:
Setting this flag causes all functions are annotated with the
"nvvm-f32ftz" = "true" attribute.

In addition, we annotate the module with "nvvm-reflect-ftz" set
to 0 or 1, depending on whether -cuda-flush-denormals-to-zero is set.
This is read by the NVVMReflect pass.

Reviewers: tra, rnk

Subscribers: cfe-commits

Differential Revision: http://reviews.llvm.org/D18671

llvm-svn: 265435

show more ...

Fix serialization/deserialization for __uuidof

I broke this back in r264529 because I forgot to serialize the UuidAttr
member. Fix this by replacing the UuidAttr with a StringRef which is
properly

Fix serialization/deserialization for __uuidof

I broke this back in r264529 because I forgot to serialize the UuidAttr
member. Fix this by replacing the UuidAttr with a StringRef which is
properly serialized and deserialized.

llvm-svn: 264562

show more ...

Use the correct alignment for uuid descriptors

The _GUID_ descriptors emitted by MSVC have alignment 8 for 64-bit
builds: we should do the same if the linker picks the "wrong" COMDAT.

llvm-svn: 264

Use the correct alignment for uuid descriptors

The _GUID_ descriptors emitted by MSVC have alignment 8 for 64-bit
builds: we should do the same if the linker picks the "wrong" COMDAT.

llvm-svn: 264530

show more ...

Improve the representation of CXXUuidofExpr

Keep a pointer to the UuidAttr that the CXXUuidofExpr corresponds to.
This makes translating from __uuidof to the underlying constant a lot
more straightf

Improve the representation of CXXUuidofExpr

Keep a pointer to the UuidAttr that the CXXUuidofExpr corresponds to.
This makes translating from __uuidof to the underlying constant a lot
more straightforward.

llvm-svn: 264529

show more ...

Attach profile summary information to Module.

Differential Revision: http://reviews.llvm.org/D18289

llvm-svn: 264342

CodeGen: Mark functions used in vtables as unnamed_addr.

This marks virtual function declarations, as well as runtime library functions
__cxa_pure_virtual, __cxa_deleted_virtual and _purecall, as un

CodeGen: Mark functions used in vtables as unnamed_addr.

This marks virtual function declarations, as well as runtime library functions
__cxa_pure_virtual, __cxa_deleted_virtual and _purecall, as unnamed_addr. This
will allow us to correctly form relative references to them from vtables in
the relative vtable ABI.

Differential Revision: http://reviews.llvm.org/D18071

llvm-svn: 263464

show more ...

[OPENMP 4.0] Codegen for 'declare reduction' construct.

Emit function for 'combiner' part of 'declare reduction' construct and
'initialilzer' part, if any.

llvm-svn: 262699

[OPENMP 4.0] Initial support for 'omp declare reduction' construct.

Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct.
User-defined reductions are define

[OPENMP 4.0] Initial support for 'omp declare reduction' construct.

Add parsing, sema analysis and serialization/deserialization for 'declare reduction' construct.
User-defined reductions are defined as

#pragma omp declare reduction( reduction-identifier : typename-list : combiner ) [initializer ( initializer-expr )]
These custom reductions may be used in 'reduction' clauses of OpenMP constructs. The combiner specifies how partial results can be combined into a single value. The
combiner can use the special variable identifiers omp_in and omp_out that are of the type of the variables being reduced with this reduction-identifier. Each of them will
denote one of the values to be combined before executing the combiner. It is assumed that the special omp_out identifier will refer to the storage that holds the resulting
combined value after executing the combiner.
As the initializer-expr value of a user-defined reduction is not known a priori the initializer-clause can be used to specify one. Then the contents of the initializer-clause
will be used as the initializer for private copies of reduction list items where the omp_priv identifier will refer to the storage to be initialized. The special identifier
omp_orig can also appear in the initializer-clause and it will refer to the storage of the original variable to be reduced.
Differential Revision: http://reviews.llvm.org/D11182

llvm-svn: 262582

show more ...

[PGO] Change profile use cc1 option to handle IR level profiles

This patch changes cc1 option for PGO profile use from
-fprofile-instr-use=<path> to -fprofile-instrument-use-path=<path>.
-fprofile-i

[PGO] Change profile use cc1 option to handle IR level profiles

This patch changes cc1 option for PGO profile use from
-fprofile-instr-use=<path> to -fprofile-instrument-use-path=<path>.
-fprofile-instr-use=<path> is now a driver only option.

In addition to decouple the cc1 option from the driver level option, this patch
also enables IR level profile use. cc1 option handling now reads the profile
header and sets CodeGenOpt ProfileUse (valid values are {None, Clang, LLVM}
-- this is a common enum for -fprofile-instrument={}, for the profile
instrumentation), and invoke the pipeline to enable the respective PGO use pass.

Reviewers: silvas, davidxl

Differential Revision: http://reviews.llvm.org/D17737

llvm-svn: 262515

show more ...

Serialize `#pragma detect_mismatch`.

This is like r262493, but for pragma detect_mismatch instead of pragma comment.
The two pragmas have similar behavior, so use the same approach for both.

llvm-s

Serialize `#pragma detect_mismatch`.

This is like r262493, but for pragma detect_mismatch instead of pragma comment.
The two pragmas have similar behavior, so use the same approach for both.

llvm-svn: 262506

show more ...

[CUDA] Emit host-side 'shadows' for device-side global variables

... and register them with CUDA runtime.

This is needed for commonly used cudaMemcpy*() APIs that use address of
host-side shadow to

[CUDA] Emit host-side 'shadows' for device-side global variables

... and register them with CUDA runtime.

This is needed for commonly used cudaMemcpy*() APIs that use address of
host-side shadow to access their counterparts on device side.

Fixes PR26340

Differential Revision: http://reviews.llvm.org/D17779

llvm-svn: 262498

show more ...

Serialize `#pragma comment`.

`#pragma comment` was handled by Sema calling a function on ASTConsumer, and
CodeGen then implementing this function and writing things to its output.

Instead, introduc

Serialize `#pragma comment`.

`#pragma comment` was handled by Sema calling a function on ASTConsumer, and
CodeGen then implementing this function and writing things to its output.

Instead, introduce a PragmaCommentDecl AST node and hang one off the
TranslationUnitDecl for every `#pragma comment` line, and then use the regular
serialization machinery. (Since PragmaCommentDecl has codegen relevance, it's
eagerly deserialized.)

http://reviews.llvm.org/D17799

llvm-svn: 262493

show more ...

Add whole-program vtable optimization feature to Clang.

This patch introduces the -fwhole-program-vtables flag, which enables the
whole-program vtable optimization feature (D16795) in Clang.

Differ

Add whole-program vtable optimization feature to Clang.

This patch introduces the -fwhole-program-vtables flag, which enables the
whole-program vtable optimization feature (D16795) in Clang.

Differential Revision: http://reviews.llvm.org/D16821

llvm-svn: 261767

show more ...

Re-apply for the 2nd-time r259977 - [OpenMP] Reorganize code to allow specialized code generation for different devices.

This was reverted by r260036, but was not the cause of the problem in the bui

Re-apply for the 2nd-time r259977 - [OpenMP] Reorganize code to allow specialized code generation for different devices.

This was reverted by r260036, but was not the cause of the problem in the buildbot.

llvm-svn: 260106

show more ...

Revert "Re-apply r259977 - [OpenMP] Reorganize code to allow specialized code generation for different devices."

This reverts commit r259985, as it still fails one buildbot.

llvm-svn: 260036

Re-apply r259977 - [OpenMP] Reorganize code to allow specialized code generation for different devices.

This was reverted due to a failure in a buildbot, but it turned out the failure was unrelated.

Re-apply r259977 - [OpenMP] Reorganize code to allow specialized code generation for different devices.

This was reverted due to a failure in a buildbot, but it turned out the failure was unrelated.

llvm-svn: 259985

show more ...

Revert r259977 - [OpenMP] Reorganize code to allow specialized code generation for different devices.

It triggered some problem in the configuration related with zlib and exposed in the driver.

llv

Revert r259977 - [OpenMP] Reorganize code to allow specialized code generation for different devices.

It triggered some problem in the configuration related with zlib and exposed in the driver.

llvm-svn: 259984

show more ...

[OpenMP] Reorganize code to allow specialized code generation for different devices.

Summary:
Different devices may in some cases require different code generation schemes in order to implement Open

[OpenMP] Reorganize code to allow specialized code generation for different devices.

Summary:
Different devices may in some cases require different code generation schemes in order to implement OpenMP. This is required not only for performance reasons, but also because it may not be possible to have the current (default) implementation working for these devices. E.g. GPU's cannot implement the same scheme a target such as powerpc or x86b would use, in the sense that it does not have the ability to fork threads, instead all the threads are always executing and need to be managed by the implementation.

This patch proposes a reorganization of the code in the OpenMP code generation to pave the way to have specialized implementation of OpenMP support. More than a "real" patch this is more a request for comments in order to understand if what is proposed is acceptable or if there are better/easier ways to do it.

In this patch part of the common OpenMP codegen infrastructure is moved to a new file under a new namespace (CGOpenMPCommon) so it can be shared between the default implementation and the specialized one. When CGOpenMPRuntime is created, an attempt to select a specialized implementation is done.

In the patch a specialization for nvptx targets is done which currently checks if the target is an OpenMP device and trap if it is not.

Let me know comments suggestions you may have.

Reviewers: hfinkel, carlo.bertolli, arpith-jacob, kkwli0, ABataev

Subscribers: Hahnfeld, cfe-commits, fraggamuffin, caomhin, jholewinski

Differential Revision: http://reviews.llvm.org/D16784

llvm-svn: 259977

show more ...

[cfi] Safe handling of unaddressable vtable pointers (clang).

Avoid crashing when printing diagnostics for vtable-related CFI
errors. In diagnostic mode, the frontend does an additional check of
the

[cfi] Safe handling of unaddressable vtable pointers (clang).

Avoid crashing when printing diagnostics for vtable-related CFI
errors. In diagnostic mode, the frontend does an additional check of
the vtable pointer against the set of all known vtable addresses and
lets the runtime handler know if it is safe to inspect the vtable.

http://reviews.llvm.org/D16823

llvm-svn: 259716

show more ...

[CUDA] Do not allow dynamic initialization of global device side variables.

In general CUDA does not allow dynamic initialization of
global device-side variables. One exception is that CUDA allows
r

[CUDA] Do not allow dynamic initialization of global device side variables.

In general CUDA does not allow dynamic initialization of
global device-side variables. One exception is that CUDA allows
records with empty constructors as described in section E2.2.1 of
CUDA 7.5 Programming guide.

This patch applies initializer checks for all device-side variables.
Empty constructors are accepted, but no code is generated for them.

Differential Revision: http://reviews.llvm.org/D15305

llvm-svn: 259592

show more ...

Move DebugInfoKind into its own header to cut the cyclic dependency edge from Driver to Frontend.

llvm-svn: 259489

Use a consistent spelling for vtables.

llvm-svn: 259137

[MS ABI] Allow a member pointers' converted type to change

Member pointers in the MS ABI are tricky for a variety of reasons.
The size of a member pointer is indeterminate until the program reaches

[MS ABI] Allow a member pointers' converted type to change

Member pointers in the MS ABI are tricky for a variety of reasons.
The size of a member pointer is indeterminate until the program reaches
a point where the representation is required to be known. However,
*pointers* to member pointers may exist without knowing the pointee
type's representation. In these cases, we synthesize an opaque LLVM
type for the pointee type.

However, we can be in a situation where the underlying member pointer's
representation became known mid-way through the program. To account for
this, we attempted to manicure CodeGen's type-cache so that we can
replace the opaque member pointer type with the real deal while leaving
the pointer types unperturbed. This, unfortunately, is a problematic
approach to take as we will violate CodeGen's invariants.

These violations are mostly harmless but let's do the right thing
instead: invalidate the type-cache if a member pointer's LLVM
representation changes.

This fixes PR26313.

llvm-svn: 258839

show more ...