[dllimport] Look through typedefs and arrays in HasNonDllImportDtor

The function is used to check whether a type is a class with
non-dllimport destructor. It needs to look through typedefs and array

[dllimport] Look through typedefs and arrays in HasNonDllImportDtor

The function is used to check whether a type is a class with
non-dllimport destructor. It needs to look through typedefs and array
types.

llvm-svn: 295257

show more ...

Prototype of modules codegen

First pass at generating weak definitions of inline functions from module files
(& skipping (-O0) or emitting available_externally (optimizations)
definitions where thos

Prototype of modules codegen

First pass at generating weak definitions of inline functions from module files
(& skipping (-O0) or emitting available_externally (optimizations)
definitions where those modules are used).

External functions defined in modules are emitted into the modular
object file as well (this may turn an existing ODR violation (if that
module were imported into multiple translations) into valid/linkable
code).

Internal symbols (static functions, for example) are not correctly
supported yet. The symbol will be produced, internal, in the modular
object - unreferenceable from the users.

Reviewers: rsmith

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

llvm-svn: 293456

show more ...

Re-commit "Don't inline dllimport functions referencing non-imported methods"

This re-commits r292522 with the addition that it also handles calls
through pointer to member functions without crashin

Re-commit "Don't inline dllimport functions referencing non-imported methods"

This re-commits r292522 with the addition that it also handles calls
through pointer to member functions without crashing.

llvm-svn: 292856

show more ...

Revert "Don't inline dllimport functions referencing non-imported methods"

This reverts commit r292522. It appears to be causing crashes in builds
using dllimport.

llvm-svn: 292643

Don't inline dllimport functions referencing non-imported methods

This is another follow-up to r246338. I had assumed methods were already
handled by the AST visitor, but turns out they weren't.

ll

Don't inline dllimport functions referencing non-imported methods

This is another follow-up to r246338. I had assumed methods were already
handled by the AST visitor, but turns out they weren't.

llvm-svn: 292522

show more ...

Remove now redundant code that ensured debug info for class definitions was emitted under certain circumstances

Introduced in r181561 - it may've been subsumed by work done to allow
emission of decl

Remove now redundant code that ensured debug info for class definitions was emitted under certain circumstances

Introduced in r181561 - it may've been subsumed by work done to allow
emission of declarations for vtable types while still emitting some of
their member functions correctly for those declarations. Whatever the
reason, the tests pass without this code now.

llvm-svn: 292439

show more ...

[WebAssembly] Add minimal support for the new wasm object format triple.

llvm-svn: 292269

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