for __unknown_anytype resolution to destructively modify the AST. So that's
what it does now, which significantly simplifies some of the implementation.
Normal member calls work pretty cleanly now, and I added support for
propagating unknown-ness through &.
llvm-svn: 129331
The idea is that you can create a VarDecl with an unknown type, or a
FunctionDecl with an unknown return type, and it will still be valid to
access that object as long as you explicitly cast it at every use. I'm
still going back and forth about how I want to test this effectively, but
I wanted to go ahead and provide a skeletal implementation for the LLDB
folks' benefit and because it also improves some diagnostic goodness for
placeholder expressions.
llvm-svn: 129065
__block object copy/dispose helpers for C++ objects with those for
different variables with completely different semantics simply because
they happen to both be no more aligned than a pointer.
Found by inspection.
Also, internalize most of the helper generation logic within CGBlocks.cpp,
and refactor it to fit my peculiar aesthetic sense.
llvm-svn: 128618
Emit them instead with the linkage of the VTT.
I'm actually really ambivalent about this; it's what GCC does, but outside
of improving code size (if the linkage is coalescing), I'm not sure it's
at all relevant. Construction vtables are naturally referenced only by the
VTT, which is itself only referenced by complete-object constructors and
destructors; giving the construction vtables possibly-external linkage is
important if you have an optimization that drills through the VTT to a
reference to a particular construction vtable which it cannot just emit
itself.
llvm-svn: 128374
Issue this as an IR-gen error; it's not really worthwhile doing this
"right", i.e. in Sema, because IR gen knows a lot of tricks beyond
what the constant evaluator knows.
llvm-svn: 127854
simplify the logic of initializing function parameters so that we don't need
both a variable declaration and a type in FunctionArgList. This also means
that we need to propagate the CGFunctionInfo down in a lot of places rather
than recalculating it from the FAL. There's more we can do to eliminate
redundancy here, and I've left FIXMEs behind to do it.
llvm-svn: 127314
21 int main() {
22 A a;
For example, here user would expect to stop at line 22, even if A's constructor leads to a call through CXXDefaultArgExpr.
This fixes ostream-defined.exp regression from gdb testsuite.
llvm-svn: 127164
invocation function into the debug info. Rather than faking up a class,
which is tricky because of the custom layout we do, we just emit a struct
directly from the layout information we've already got.
Also, don't emit an unnecessarily parameter alloca for this "variable".
llvm-svn: 126255
- Have CGM precompute a number of commonly-used types
- Have CGF copy that during initialization instead of recomputing them
- Use TBAA info when initializing a parameter variable
- Refactor the scalar ++/-- code
llvm-svn: 125562
right for anonymous struct/union members led to me discovering some
seemingly broken code in that area of Sema, which I fixed, partly by
changing the representation of member pointer constants so that
IndirectFieldDecls aren't expanded. This led to assorted cleanups with
member pointers in CodeGen, and while I was doing that I saw some random
other things to clean up.
llvm-svn: 124785
is not defined in the current translation unit. Doing so lead to compile errors
such as PR9114.
Instead, when CodeGen is building the vtable, don't try to emit a definition
for functions that aren't marked used in the current translation unit.
Fixes PR9114.
llvm-svn: 124768
process, perform a number of refactorings:
- Move MiscNameMangler member functions to MangleContext
- Remove GlobalDecl dependency from MangleContext
- Make MangleContext abstract and move Itanium/Microsoft functionality
to their own classes/files
- Implement ASTContext::createMangleContext and have CodeGen use it
No (intended) functionality change.
llvm-svn: 123386
data members by delaying the emission of the initializer until after
linkage and visibility have been set on the global. Also, don't
emit a guard unless the variable actually ends up with vague linkage,
and don't use thread-safe statics in any case.
llvm-svn: 118336
independently of whether they're definitions, then teach IR generation to
ignore non-explicit visibility when emitting declarations. Use this to
make sure that RTTI, vtables, and VTTs get the right visibility.
More of rdar://problem/8613093
llvm-svn: 117781
more closely parallel the computation of linkage. This gets us to a state
much closer to what gcc emits, modulo bugs, which will undoubtedly arise in
abundance.
llvm-svn: 117147
class; they should just be completely opaque throughout IR gen now,
although I haven't really audited that.
Fix a bug apparently inherited from gcc-4.2 where we failed to null-check
member data pointers when performing derived-to-base or base-to-derived
conversions on them.
llvm-svn: 111789
Make CGT defer to the ABI on all member pointer types.
This requires giving CGT a handle to the ABI.
It's way easier to make that work if we avoid lazily creating the ABI.
Make it so.
llvm-svn: 111786
duplication between the constant and non-constant paths in all of this.
Implement ARM ABI semantics for member pointer constants and conversion.
llvm-svn: 111772
This takes some trickery since CastExpr has subclasses (and indeed,
is abstract).
Also, smoosh the CastKind into the bitfield from Expr.
Drops two words of storage from Expr in the common case of expressions
which don't need inheritance paths. Avoids a separate allocation and
another word of overhead in cases needing inheritance paths. Also has
the advantage of not leaking memory, since destructors for AST nodes are
never run.
llvm-svn: 110507
Apply hidden visibility to most RTTI; libstdc++ does not rely on exact
pointer equality for the type info (just the type info names). Apply
the same optimization to RTTI that we do to vtables.
Fixes PR5962.
llvm-svn: 110192
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.
llvm-svn: 109784
- 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.
llvm-svn: 108482
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
llvm-svn: 108379
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. :)
llvm-svn: 107739
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.
llvm-svn: 105151
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.
llvm-svn: 104630
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>.
llvm-svn: 104610
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.
llvm-svn: 104581
"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.
llvm-svn: 103718
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.
llvm-svn: 99012
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.
llvm-svn: 98441
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.
llvm-svn: 97733
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.
llvm-svn: 96842
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.
llvm-svn: 96451
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.
llvm-svn: 93118
linkage of vtables. Before this, we were emitting RTTI names for
template instantiations with strong external linkage rather than with
weak ODR linkage.
llvm-svn: 92857
the constructor. This doesn't handle cases requiring the VTT at the moment,
and generates unnecessary stores, but I think it's essentially correct.
llvm-svn: 91731
operators, and destructors. Avoids generating declarations/definitions of
trivial constructors/destructors, and makes sure the trivial copy assignment
operator is generated when necessary.
llvm-svn: 89943
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.
llvm-svn: 87021
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. :)
llvm-svn: 81756
- Track implicit instantiations vs. the not-yet-supported explicit
specializations
- Give implicit instantiations of function templates (and member
functions of class templates) linkonce_odr linkage.
- Improve name mangling for function template specializations,
including the template arguments of the instantiation and the return
type of the function.
Note that our name-mangling is improved, but not correct: we still
don't mangle substitutions, although the manglings we produce can be
demangled.
llvm-svn: 74466
to allow us to support generation of deferred ctors/dtors.
It looks like codegen isn't emitting a call to the dtor in
member-functions.cpp:test2, but when it does, its body should
get emitted.
llvm-svn: 71594
tentative definitions off to the ASTConsumer at the end of the
translation unit.
Eliminate CodeGen's internal tracking of tentative definitions, and
instead hook into ASTConsumer::CompleteTentativeDefinition. Also,
tweak the definition-deferal logic for C++, where there are no
tentative definitions.
Fixes <rdar://problem/6808352>, and will make it much easier for
precompiled headers to cope with tentative definitions in the future.
llvm-svn: 69681
- PR3980.
- <rdar://problem/6762287> [irgen] crash when generating tentative
definition of incomplete structure
- This also avoids creating common definitions for things which are
later overwritten.
- XFAIL'ed external-defs.c, it isn't completing types properly yet.
llvm-svn: 69231
- Pull out SetCommonAttributes, which handles the things common to
aliases, methods, functions, and variables.
- Pull out SetLLVMFunctionAttributesForDefinition, which handles the
LLVM attributes which we only want to apply to a definition (like
noinline and alwaysinline).
- Kill SetGVDeclarationAttributes (inlined into SetFunctionAttributes
and specialized).
- Kill SetFunctionAttributesForDefinition (inlined into sole caller).
- Inline SetGVDefinitionAttributes into SetMethodAttributes and
specialize.
- Rename SetGVDefinitionAttributes to SetFunctionDefinitionAttributes.
This is supposed to be a no functionality change commit, but I may
have made a mistake.
llvm-svn: 69036
functionality, fixing a crash on the attached testcase. Eliminate the
BuiltinFunctions cache, as it can contain dangling pointers. This fixes
a bunch of valgrind errors on test/CodeGen/builtins.c
llvm-svn: 67484
CodeGenModule::CreateRuntimeVariable.
- No real functionality change; although we now assert on silly
things like:
--
int objc_exception_throw;
void f0() { @throw(@"A"); }
--
instead of accepting it.
llvm-svn: 66292
BlockModule. No functionality change. This should help people that
don't want to know anything about blocks not be confused by the
overloaded use of the term block or nor want to see all the blocks
goop.
llvm-svn: 66042
we ensure that things added to the module can be found even when they
are not in GlobalDeclMap. The later is for increased flexibility,
should someone want to do something tricky like extern "Ada" in the
same module.
llvm-svn: 65657
IRgen no longer relies on isConstantInitializer, instead we just try
to emit the constant. If that fails then in C we emit an error
unsupported (this occurs when Sema accepted something that it doesn't
know how to fold, and IRgen doesn't know how to emit) and in C++ we
emit a guarded initializer.
This ends up handling a few more cases, because IRgen was actually
able to emit some of the constants Sema accepts but can't Evaluate().
For example, PR3398.
llvm-svn: 64780
- Fix emission of static functions with constructor attribute while I
was here.
<rdar://problem/6140899> [codegen] "static" and attribute-constructor interact poorly
llvm-svn: 64488
ABI to the CodeGen library. Since C++ code-generation is so
incomplete, we can't exercise much of this mangling code. However, a
few smoke tests show that it's doing the same thing as GCC. When C++
codegen matures, we'll extend the ABI tester to verify name-mangling
as well, and complete the implementation here.
At this point, the major client of name mangling is in the uses of the
new "overloadable" attribute in C, which allows overloading. Any
"overloadable" function in C (or in an extern "C" block in C++) will
be mangled the same way that the corresponding C++ function would be
mangled.
llvm-svn: 64413
When emitting the static variables we need to make sure that the order is preserved.
Fix this by making StaticDecls a std::list which has O(1) random removal.
llvm-svn: 61621
collisions.
- Provide CodeGenModule::CreateRuntimeFunction which guarantees that
the function it creates will have the provided name in the final
module. This allows the runtime to have its functions protected
from declarations of the same name in the source code.
- One could argue that this is a reason to abuse the llvm::Module
namespace for dealing with function redeclarations. However, that
approach seems conceptually flawed to me. This one also happens to
be somewhat more efficient.
No functionality change.
llvm-svn: 56899
s/ParamAttr/Attribute/g
s/PAList/AttrList/g
s/FnAttributeWithIndex/AttributeWithIndex/g
s/FnAttr/Attribute/g
This sets the stage
- to implement function notes as function attributes and
- to distinguish between function attributes and return value attributes.
llvm-svn: 56623
- Added CodeGenTypes::GetFunctionType, taking a CGFunctionInfo.
- Updated Obj-C runtimes to use this instead of rolling the
llvm::FunctionType by hand.
- Killed CodeGenTypes::{ConvertReturnType, DecodeArgumentTypes}.
Add ABIArgInfo class to encapsulate ABI decision of how to lower types
to LLVM.
- Will move to target sometime soon.
llvm-svn: 56047
- Realized these functions will eventually need access to more data,
moved to CodeGenModule. Eventually they should probably live
together in some other helper class.
llvm-svn: 56039
aliases.
- Attributes specific to a definition are only set when the
definition is seen.
- Alias generation is delayed until the end of the module; necessary
since the alias may reference forward.
- Fixes: PR2743, <rdr://6140807&6094512>
- Improves: <rdr://6095112> (added XFAIL)
Also, print module on verification failures.
llvm-svn: 55966
- Add CGCall.h for dealing with ABI issues related to calls.
- Add CGFunctionInfo and CGCallInfo for capturing ABI relevant
information about functions and calls.
- Isolate LLVM parameter attribute handling inside CGCall.cpp
llvm-svn: 55963
- Only supports simple assignment and atomic semantics are ignored.
- Not quite usable yet because the methods do not actually get added
to the class metadata.
- Added ObjCPropertyDecl::getSetterKind (one of Assign, Copy, Retain).
- Rearrange CodeGenFunction so synthesis can reuse function prolog /
epilog code.
llvm-svn: 55365
- Add CodeGenModule::EmitTopLevelDecl which uses switch on kind
instead of ugly & slow dyn_cast chains.
- Drop some simple forwarding methods into the ObjC runtime.
- Privatize appropriate methods.
llvm-svn: 54827
- Returns addr of constant for argument + '\0'.
- I couldn't think of a better name.
- Move appropriate users of GetAddrOfConstantString to this.
Rename getStringForStringLiteral to GetStringForStringLiteral.
Add GetAddrOfConstantStringFromLiteral
- This combines GetAddrOfConstantString and
GetStringForStringLiteral. This method can be, but is not yet, more
efficient.
Change GetAddrOfConstantString to not add terminating '\0'
- <rdar://problem/6140956>
llvm-svn: 54768
ObjCProtocolDecl directly.
Implement CodeGen support for forward protocol decls (no-ops are so
nice to implement).
Also moved CGObjCRuntime.h out of CodeGenModule.h
llvm-svn: 54709
temporarily, I assumed GetAddrForConstantString literal was being
used consistently but it doesn't look like it is.
Factored out a CodeGenModule::getStringForStringLiteral which handles
extracting a std::string for the bytes of a StringLiteral, padded to
match the type.
Update EmitLValue to use getStringForStringLiteral, this was
previously not padding strings correctly. Good thing we only emit
strings in 4 different places!
llvm-svn: 54621
having multiple bindings from all the possible decls which
conceptually map to the same global).
- This eliminates CodeGen depending on the LLVM module for name
lookup.
- This also eliminates the need for ReplaceMapValuesWith (hurrah).
- This handles lookups for FunctionDecls correctly in the presence of
aliases, this was previously broken.
- WIP: Can still clean up & unify variable and function emission.
llvm-svn: 54382
- There is an miscompilation issue remaining due to a poor
interaction between the delayed emission of static functions and
the emission of constructors, but that already existed prior to
this change.
llvm-svn: 54258
instead of mapping the decl to a bitcast of the global to the correct
type.
- GetAddrOf{Function,GlobalVar} introduce the bitcast on every use now.
- This solves a problem where a dangling pointer could be introduced
by the RAUW done when replacing a forward or tentative
definition. See testcase for more details.
- Fixes <rdar://problem/6108358>
llvm-svn: 54211
- No (intended) functionality change.
- Primary purpose is to clearly separate (lazy) construction of
globals that are a forward declaration or tentative definition from
those that are the final definition.
- Lazy construction is now encapsulated in
GetAddrOf{Function,GlobalVar} while final definitions are
constructed in EmitGlobal{Function,Var}Definition.
- External interface for dealing with globals is now limited to
EmitGlobal and GetAddrOf{Function,GlobalVar}.
- Also updated helper functions dealing with statics, annotations,
and ctors to be private.
llvm-svn: 54179
much closer to passing the gcc struct layout tests.
It might be possible to refactor this a bit, but I'm not sure there's
actually enough common code for that to be useful.
To get the calling convention completely correct, a bit of
platform-specific code is necessary even for x86-Linux. On x86-Linux, the
alignment of function parameters is extremely strange; as far as I can tell,
it's always 4 except for SSE vectors or structs containing SSE vectors. I'm
continuing to investigate this.
llvm-svn: 51839
required for correctness in cases of copying a struct to itself or to
an overlapping struct (itself for cases like *a = *a, and overlapping
is possible with unions).
Hopefully, this won't end up being a perf issue; LLVM *should* be able
to optimize memmove to memcpy in a lot of cases, and for small copies
the generated code *should* be mostly comparable. (In reality, LLVM
is currently horrible at optimizing memmove, but that's a bug, not a
fundamental issue.)
gcc currently generates wrong code; that's
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667.
llvm-svn: 51566
lib/CodeGen/CGExpr.cpp and to change include/clang/AST/Attr.h to
use its own enum for visibility types instead of using
llvm::GlobalValue::VisibilityTypes. These changes eliminate
dependencies in the AST library on LLVM's VMCore library.
llvm-svn: 51398
This is a fairly mechanical/large change. As a result, I avoided making any changes/simplifications that weren't directly related. I did break two Analysis tests. I also have a couple FIXME's in UninitializedValues.cpp. Ted, can you take a look? If the bug isn't obvious, I am happy to dig in and fix it (since I broke it).
llvm-svn: 49748
lib dir and move all the libraries into it. This follows the main
llvm tree, and allows the libraries to be built in parallel. The
top level now enforces that all the libs are built before Driver,
but we don't care what order the libs are built in. This speeds
up parallel builds, particularly incremental ones.
llvm-svn: 48402
Peter Collingbourne