Module: Do not add any link flags when an implementation TU of a module imports
a header of that same module.

This fixes a regression caused by r280409.
rdar://problem/29930553

This is an updated v

Module: Do not add any link flags when an implementation TU of a module imports
a header of that same module.

This fixes a regression caused by r280409.
rdar://problem/29930553

This is an updated version for r291628 (which was reverted in r291688).

llvm-svn: 291689

show more ...

Deduplicate several GD.getDecl() calls into Decl * local variable.

llvm-svn: 290495

Cleanup the handling of noinline function attributes, -fno-inline,
-fno-inline-functions, -O0, and optnone.

These were really, really tangled together:
- We used the noinline LLVM attribute for -fno

Cleanup the handling of noinline function attributes, -fno-inline,
-fno-inline-functions, -O0, and optnone.

These were really, really tangled together:
- We used the noinline LLVM attribute for -fno-inline
- But not for -fno-inline-functions (breaking LTO)
- But we did use it for -finline-hint-functions (yay, LTO is happy!)
- But we didn't for -O0 (LTO is sad yet again...)
- We had weird structuring of CodeGenOpts with both an inlining
enumeration and a boolean. They interacted in weird ways and
needlessly.
- A *lot* of set smashing went on with setting these, and then got worse
when we considered optnone and other inlining-effecting attributes.
- A bunch of inline affecting attributes were managed in a completely
different place from -fno-inline.
- Even with -fno-inline we failed to put the LLVM noinline attribute
onto many generated function definitions because they didn't show up
as AST-level functions.
- If you passed -O0 but -finline-functions we would run the normal
inliner pass in LLVM despite it being in the O0 pipeline, which really
doesn't make much sense.
- Lastly, we used things like '-fno-inline' to manipulate the pass
pipeline which forced the pass pipeline to be much more
parameterizable than it really needs to be. Instead we can *just* use
the optimization level to select a pipeline and control the rest via
attributes.

Sadly, this causes a bunch of churn in tests because we don't run the
optimizer in the tests and check the contents of attribute sets. It
would be awesome if attribute sets were a bit more FileCheck friendly,
but oh well.

I think this is a significant improvement and should remove the semantic
need to change what inliner pass we run in order to comply with the
requested inlining semantics by relying completely on attributes. It
also cleans up tho optnone and related handling a bit.

One unfortunate aspect of this is that for generating alwaysinline
routines like those in OpenMP we end up removing noinline and then
adding alwaysinline. I tried a bunch of other approaches, but because we
recompute function attributes from scratch and don't have a declaration
here I couldn't find anything substantially cleaner than this.

Differential Revision: https://reviews.llvm.org/D28053

llvm-svn: 290398

show more ...

Re-commit r289252 and r289285, and fix PR31374

llvm-svn: 289787

CodeGen: fix runtime function dll storage

Properly attribute DLL storage to runtime functions. When generating the
runtime function, scan for an existing declaration which may provide an explicit
d

CodeGen: fix runtime function dll storage

Properly attribute DLL storage to runtime functions. When generating the
runtime function, scan for an existing declaration which may provide an explicit
declaration (local storage) or a DLL import or export storage from the user.
Honour that if available. Otherwise, if building with a local visibility of the
public or standard namespaces (-flto-visibility-public-std), give the symbols
local storage (it indicates a /MT[d] link, so static runtime). Otherwise,
assume that the link is dynamic, and give the runtime function dllimport
storage.

This allows for implementations to get the correct storage as long as they are
properly declared, the user to override the import storage, and in case no
explicit storage is given, use of the import storage.

llvm-svn: 289776

show more ...

Revert 289252 (and follow-up 289285), it caused PR31374

llvm-svn: 289713

Add support for non-zero null pointer for C and OpenCL

In amdgcn target, null pointers in global, constant, and generic address space take value 0 but null pointers in private and local address spac

Add support for non-zero null pointer for C and OpenCL

In amdgcn target, null pointers in global, constant, and generic address space take value 0 but null pointers in private and local address space take value -1. Currently LLVM assumes all null pointers take value 0, which results in incorrectly translated IR. To workaround this issue, instead of emit null pointers in local and private address space, a null pointer in generic address space is emitted and casted to local and private address space.

Tentative definition of global variables with non-zero initializer will have weak linkage instead of common linkage since common linkage requires zero initializer and does not have explicit section to hold the non-zero value.

Virtual member functions getNullPointer and performAddrSpaceCast are added to TargetCodeGenInfo which by default returns ConstantPointerNull and emitting addrspacecast instruction. A virtual member function getNullPointerValue is added to TargetInfo which by default returns 0. Each target can override these virtual functions to get target specific null pointer and the null pointer value for specific address space, and perform specific translations for addrspacecast.

Wrapper functions getNullPointer is added to CodegenModule and getTargetNullPointerValue is added to ASTContext to facilitate getting the target specific null pointers and their values.

This change has no effect on other targets except amdgcn target. Other targets can provide support of non-zero null pointer in a similar way.

This change only provides support for non-zero null pointer for C and OpenCL. Supporting for other languages will be added later incrementally.

Differential Revision: https://reviews.llvm.org/D26196

llvm-svn: 289252

show more ...

Introduce a type-safe enum for ForDefinition.

llvm-svn: 288289

Fix some layering violations where CGObjCMac's NSString emission was
performed at the CodeGenModule level.

Would be NFC except we now also use a different uniquing structure so
that we don't get spu

Fix some layering violations where CGObjCMac's NSString emission was
performed at the CodeGenModule level.

Would be NFC except we now also use a different uniquing structure so
that we don't get spurious conflicts if you ask for both an NSString
and a CFString for the same content (which is possible with builtins).

llvm-svn: 288287

show more ...

Hide the result of building a constant initializer. NFC.

llvm-svn: 288080

ConstantBuilder -> ConstantInitBuilder for clarity, and
move the member classes up to top level to allow forward
declarations to name them. NFC.

llvm-svn: 288079

[CodeGen] Simplify code. No functionality change intended.

llvm-svn: 287754

Remove alignment from ctors/dtors lists in an attempt to placate LTO.

llvm-svn: 287458

Introduce a helper class for building complex constant initializers. NFC.

I've adopted this in most of the places it makes sense, but v-tables
and CGObjCMac will need a second pass.

llvm-svn: 2874

Introduce a helper class for building complex constant initializers. NFC.

I've adopted this in most of the places it makes sense, but v-tables
and CGObjCMac will need a second pass.

llvm-svn: 287437

show more ...

regcall: Implement regcall Calling Conv in clang

This patch implements the register call calling convention, which ensures
as many values as possible are passed in registers. CodeGen changes
were co

regcall: Implement regcall Calling Conv in clang

This patch implements the register call calling convention, which ensures
as many values as possible are passed in registers. CodeGen changes
were committed in https://reviews.llvm.org/rL284108.

Differential Revision: https://reviews.llvm.org/D25204

llvm-svn: 285849

show more ...

[cfi] Fix missing !type annotation.

CFI (only in the cross-dso mode) fails to set !type annotations when
a function is used before it is defined.

llvm-svn: 285650

Empty the CtorLists/DtorLists once emitted.

This is essential when clang is running in incremental processing mode because
we don't want to reemit the 'tors over and over again.

Patch by Axel Nauma

Empty the CtorLists/DtorLists once emitted.

This is essential when clang is running in incremental processing mode because
we don't want to reemit the 'tors over and over again.

Patch by Axel Naumann!

Reviewed by Richard Smith and me. (https://reviews.llvm.org/D25605)

llvm-svn: 285277

show more ...

Module: emit initializers in submodules when importing the parent module.

When importing the parent module, module initializers in submodules should
be emitted.

rdar://28740482

llvm-svn: 284263

[CUDA] Emit deferred diagnostics during Sema rather than during codegen.

Summary:
Emitting deferred diagnostics during codegen was a hack. It did work,
but usability was poor, both for us as compil

[CUDA] Emit deferred diagnostics during Sema rather than during codegen.

Summary:
Emitting deferred diagnostics during codegen was a hack. It did work,
but usability was poor, both for us as compiler devs and for users. We
don't codegen if there are any sema errors, so for users this meant that
they wouldn't see deferred errors if there were any non-deferred errors.
For devs, this meant that we had to carefully split up our tests so that
when we tested deferred errors, we didn't emit any non-deferred errors.

This change moves checking for deferred errors into Sema. See the big
comment in SemaCUDA.cpp for an overview of the idea.

This checking adds overhead to compilation, because we have to maintain
a partial call graph. As a result, this change makes deferred errors a
CUDA-only concept (whereas before they were a general concept). If
anyone else wants to use this framework for something other than CUDA,
we can generalize at that time.

This patch makes the minimal set of test changes -- after this lands,
I'll go back through and do a cleanup of the tests that we no longer
have to split up.

Reviewers: rnk

Subscribers: cfe-commits, rsmith, tra

Differential Revision: https://reviews.llvm.org/D25541

llvm-svn: 284158

show more ...

[CUDA] Do a better job at detecting wrong-side calls.

Summary:
Move CheckCUDACall from ActOnCallExpr and BuildDeclRefExpr to
DiagnoseUseOfDecl. This lets us catch some edge cases we were missing,
s

[CUDA] Do a better job at detecting wrong-side calls.

Summary:
Move CheckCUDACall from ActOnCallExpr and BuildDeclRefExpr to
DiagnoseUseOfDecl. This lets us catch some edge cases we were missing,
specifically around class operators.

This necessitates a few other changes:

- Avoid emitting duplicate deferred diags in CheckCUDACall.

Previously we'd carefully placed our call to CheckCUDACall such that
it would only ever run once for a particular callsite. But now this
isn't the case.

- Emit deferred diagnostics from a template
specialization/instantiation's primary template, in addition to from
the specialization/instantiation itself. DiagnoseUseOfDecl ends up
putting the deferred diagnostics on the template, rather than the
specialization, so we need to check both.

Reviewers: rsmith

Subscribers: cfe-commits, tra

Differential Revision: https://reviews.llvm.org/D24573

llvm-svn: 283637

show more ...

[CUDA] Destroy deferred diagnostics before destroying the ASTContext's PartialDiagnostic allocator.

Summary:
This will let us (in a separate patch) allocate deferred diagnostics in
the ASTContext's

[CUDA] Destroy deferred diagnostics before destroying the ASTContext's PartialDiagnostic allocator.

Summary:
This will let us (in a separate patch) allocate deferred diagnostics in
the ASTContext's PartialDiagnostic arena.

Reviewers: rnk

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D25260

llvm-svn: 283271

show more ...

Move UTF functions into namespace llvm.

Summary:
This lets people link against LLVM and their own version of the UTF
library.

I determined this only affects llvm, clang, lld, and lldb by running

$

Move UTF functions into namespace llvm.

Summary:
This lets people link against LLVM and their own version of the UTF
library.

I determined this only affects llvm, clang, lld, and lldb by running

$ git grep -wl 'UTF[0-9]\+\|\bConvertUTF\bisLegalUTF\|getNumBytesFor' | cut -f 1 -d '/' | sort | uniq
clang
lld
lldb
llvm

Tested with

ninja lldb
ninja check-clang check-llvm check-lld

(ninja check-lldb doesn't complete for me with or without this patch.)

Reviewers: rnk

Subscribers: klimek, beanz, mgorny, llvm-commits

Differential Revision: https://reviews.llvm.org/D24996

llvm-svn: 282822

show more ...

CodeGen: simplify the logic a slight bit

Move the definition of `getTriple()` into the header. It would just call
`getTarget().getTriple()`. Inline the definition to allow the compiler to see
the

CodeGen: simplify the logic a slight bit

Move the definition of `getTriple()` into the header. It would just call
`getTarget().getTriple()`. Inline the definition to allow the compiler to see
the same amount of the layout as previously. Remove the more verbose
`getTarget().getTriple()` in favour of `getTriple()`.

llvm-svn: 281487

show more ...

Also don't inline dllimport functions referring to non-dllimport constructors.

The AST walker wasn't visiting CXXConstructExprs before.

This is a follow-up to r281395.

llvm-svn: 281413

Try harder to not inline dllimport functions referencing non-dllimport functions

In r246338, code was added to check for this, but it failed to take into
account implicit destructor invocations beca

Try harder to not inline dllimport functions referencing non-dllimport functions

In r246338, code was added to check for this, but it failed to take into
account implicit destructor invocations because those are not reflected
in the AST. This adds a separate check for them.

llvm-svn: 281395

show more ...