DeclIsRequiredFunctionOrFileScopedVar.
This is essentially a CodeGen predicate that is also needed by the PCH mechanism to determine whether a decl
needs to be deserialized during PCH loading for codegen purposes.
Since this logic is shared by CodeGen and the PCH mechanism, move it to the ASTContext,
thus CodeGenModule's GetLinkageForFunction/GetLinkageForVariable and the GVALinkage enum is moved out of CodeGen.
This fixes current (and avoids future) codegen-from-PCH bugs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@109784 91177308-0d34-0410-b5e6-96231b3b80d8
- This issue here is that /usr/include/Blocks.h wants to define some of the
block runtime globals as weak, depending on the target. This doesn't work in
Clang because we aren't using the AST decl for these globals.
- The fix is a pretty gross hack which just watches all the decls for the
specific blocks globals we need to know about; if we see one we use it,
otherwise we use the hand coded type.
In time, I would like to clean this up by changing IRgen to ask Sema/AST for
the decl, which would then be lazily loaded from the builtin table if
necessary. This could be used in a whole host of places in IRgen and would
get rid of a lot of grotty hand coding of LLVM IR; however, we need some
extra Sema support for this as well as support for builtin global variables.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108482 91177308-0d34-0410-b5e6-96231b3b80d8
the order they appeared in the translation unit. If they get emitted, put them
in their proper order. Fixes rdar://problem/7458115
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108477 91177308-0d34-0410-b5e6-96231b3b80d8
whether to use objc_msgSend_fpret; the choice is target dependent, not Obj-C ABI
dependent.
- <rdar://problem/8139758> arm objc _objc_msgSend_fpret bug
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108379 91177308-0d34-0410-b5e6-96231b3b80d8
emit metadata associating allocas and global values with a Decl*. This feature
is controlled by an option that (intentionally) cannot be enabled on the command
line.
To use this feature, simply set
CodeGenOptions.EmitDeclMetadata = true;
and then interpret the completely underspecified metadata. :)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@107739 91177308-0d34-0410-b5e6-96231b3b80d8
isn't possible to compute.
This patch is mostly refactoring; the key change is the addition of the code
starting with the comment, "Check whether the function has a computable LLVM
signature." The solution here is essentially the same as the way the
vtable code handles such functions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@105151 91177308-0d34-0410-b5e6-96231b3b80d8
This class only supports name mangling (which is apparently used during C/ObjC
codegen). For now only the Itanium C++ ABI is supported. Patches to add a
second C++ ABI are forthcoming.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104630 91177308-0d34-0410-b5e6-96231b3b80d8
variables within blocks. We loosely follow GCC's mangling, but since
these are always internal symbols the names don't really matter. I
intend to revisit block mangling later, because GCC's mangling is
rather verbose. <rdar://problem/8015719>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104610 91177308-0d34-0410-b5e6-96231b3b80d8
variables should have that linkage. Otherwise, its static local
variables should have internal linkage. To avoid computing this excessively,
set a function's linkage before we emit code for it.
Previously we were assigning weak linkage to the static variables of
static inline functions in C++, with predictably terrible results. This
fixes that and also gives better linkage than 'weak' when merging is required.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@104581 91177308-0d34-0410-b5e6-96231b3b80d8
"used" (e.g., we will refer to the vtable in the generated code) and
when they are defined (i.e., because we've seen the key function
definition). Previously, we were effectively tracking "potential
definitions" rather than uses, so we were a bit too eager about emitting
vtables for classes without key functions.
The new scheme:
- For every use of a vtable, Sema calls MarkVTableUsed() to indicate
the use. For example, this occurs when calling a virtual member
function of the class, defining a constructor of that class type,
dynamic_cast'ing from that type to a derived class, casting
to/through a virtual base class, etc.
- For every definition of a vtable, Sema calls MarkVTableUsed() to
indicate the definition. This happens at the end of the translation
unit for classes whose key function has been defined (so we can
delay computation of the key function; see PR6564), and will also
occur with explicit template instantiation definitions.
- For every vtable defined/used, we mark all of the virtual member
functions of that vtable as defined/used, unless we know that the key
function is in another translation unit. This instantiates virtual
member functions when needed.
- At the end of the translation unit, Sema tells CodeGen (via the
ASTConsumer) which vtables must be defined (CodeGen will define
them) and which may be used (for which CodeGen will define the
vtables lazily).
From a language perspective, both the old and the new schemes are
permissible: we're allowed to instantiate virtual member functions
whenever we want per the standard. However, all other C++ compilers
were more lazy than we were, and our eagerness was both a performance
issue (we instantiated too much) and a portability problem (we broke
Boost test cases, which now pass).
Notes:
(1) There's a ton of churn in the tests, because the order in which
vtables get emitted to IR has changed. I've tried to isolate some of
the larger tests from these issues.
(2) Some diagnostics related to
implicitly-instantiated/implicitly-defined virtual member functions
have moved to the point of first use/definition. It's better this
way.
(3) I could use a review of the places where we MarkVTableUsed, to
see if I missed any place where the language effectively requires a
vtable.
Fixes PR7114 and PR6564.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@103718 91177308-0d34-0410-b5e6-96231b3b80d8
- So much typing, so little gain...
Also, rename the __cxx_global_initialization function just to match llvm-gcc.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@99039 91177308-0d34-0410-b5e6-96231b3b80d8
shadowing it in the GlobalDeclMap. Eliminates the string-uniquing
requirement for mangled names, which should help C++ codegen times a little.
Forces us to do string lookups instead of pointer lookups, which might hurt
codegen times a little across the board. We'll see how it plays out.
Removing the string-uniquing requirement implicitly fixes any bugs like
PR6635 which arose from the fact that we had multiple uniquing tables for
different kinds of identifiers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@99012 91177308-0d34-0410-b5e6-96231b3b80d8
iterations of this patch gave explicit template instantiation
link-once ODR linkage, which permitted the back end to eliminate
unused symbols. Weak ODR linkage still requires the symbols to be
generated.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@98441 91177308-0d34-0410-b5e6-96231b3b80d8
Clang's support for weakref is now better than llvm-gcc's :-)
We don't introduce a new symbol and we correctly mark undefined references weak only if there is no
definition or regular undefined references in the same file.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97733 91177308-0d34-0410-b5e6-96231b3b80d8
1) emit base destructors as aliases to their unique base class destructors
under some careful conditions. This is enabled for the same targets that can
support complete-to-base aliases, i.e. not darwin.
2) Emit non-variadic complete constructors for classes with no virtual bases
as calls to the base constructor. This is enabled on all targets and in
theory can trigger in situations that the alias optimization can't (mostly
involving virtual bases, mostly not yet supported).
These are bundled together because I didn't think it worthwhile to split them,
not because they really need to be.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@96842 91177308-0d34-0410-b5e6-96231b3b80d8
and destructors when the two entities are semantically identical, i.e. when
the class has no virtual base classes. We only do this for linkage types
for which aliases are supported, i.e. internal and external, i.e. not linkonce.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@96451 91177308-0d34-0410-b5e6-96231b3b80d8
1. Add helper class for sema checks for target attributes
2. Add helper class for codegen of target attributes
As a proof-of-concept - implement msp430's 'interrupt' attribute.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93118 91177308-0d34-0410-b5e6-96231b3b80d8
linkage of vtables. Before this, we were emitting RTTI names for
template instantiations with strong external linkage rather than with
weak ODR linkage.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92857 91177308-0d34-0410-b5e6-96231b3b80d8
the constructor. This doesn't handle cases requiring the VTT at the moment,
and generates unnecessary stores, but I think it's essentially correct.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91731 91177308-0d34-0410-b5e6-96231b3b80d8
generation, and make sure we generate thunks when the function is defined
rather than when the vtable is defined.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90722 91177308-0d34-0410-b5e6-96231b3b80d8
operators, and destructors. Avoids generating declarations/definitions of
trivial constructors/destructors, and makes sure the trivial copy assignment
operator is generated when necessary.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89943 91177308-0d34-0410-b5e6-96231b3b80d8
Refine the VTT entries for virtual bases to refer to the complete
object's vtable instead of constructor vtables.
Refine the AddressPoint calculations for VTT entries for virtual bases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@87021 91177308-0d34-0410-b5e6-96231b3b80d8
The decl wasn't being passed down, which meant that function attributes were not
being set correctly. This is particularly important for ARM, since it wants to
override the calling convention. Instead we would emit the builtin with the
wrong calling convention, and instcombine would come along and merrily shred all
the calls to it. :)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@81756 91177308-0d34-0410-b5e6-96231b3b80d8
Argyrios Kyrtzidis