This adds a warning that triggers when profile data doesn't match for
the source that's being compiled with -fprofile-instr-use=. This fires
only once per translation unit, as warning on every mismatched
function would be quite noisy.
llvm-svn: 206322
COFF doesn't have mergeable sections so LLVM/clang's normal tactics for
string deduplication will not have any effect.
To remedy this we place each string inside it's own section and mark
the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the
string has an external name that we can generate from it's contents.
To be compatible with MSVC, we must use their scheme. Otherwise identical
strings in translation units from clang may not be deduplicated with
translation units in MSVC.
This fixes PR18248.
N.B. We will not attempt to do anything with a string literal which is not of
type 'char' or 'wchar_t' because their compiler does not support unicode
string literals as of this date. Further, we avoid doing this if
either -fwritable-strings or -fsanitize=address are present.
This reverts commit r204596.
llvm-svn: 204675
COFF doesn't have mergeable sections so LLVM/clang's normal tactics for
string deduplication will not have any effect.
To remedy this we place each string inside it's own section and mark
the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the
string has an external name that we can generate from it's contents.
To be compatible with MSVC, we must use their scheme. Otherwise identical
strings in translation units from clang may not be deduplicated with
translation units in MSVC.
This fixes PR18248.
N.B. We will not attempt to do anything with a string literal which is not of
type 'char' or 'wchar_t' because their compiler does not support unicode
string literals as of this date.
llvm-svn: 204562
This updates CodeGenPGO to use the ProfileDataReader introduced to
llvm in r203703 and the new API for writing out the profile introduced
to compiler-rt in r203710.
llvm-svn: 203711
LLVM currently has a hack (shouldEmitUsedDirectiveFor) that causes it to not
print no_dead_strip for symbols starting with 'l' or 'L'. These are exactly the
ones that the clang's objc codegen is producing. The net result, is that it is
equivalent to llvm.compiler.used.
The need for putting the private symbol in llvm.compiler.used should be clear
(the objc runtime uses them). The reason for also putting the weak symbols in
it is for LTO: ld64 will not ask us to preserve the it.
llvm-svn: 203172
'create' functions conventionally return a pointer, not a reference.
Also use an OwningPtr to get replace the delete of a reference member.
No functional change.
llvm-svn: 198126
Thread an optional GV down to EmitGlobalFunctionDefinition so that it can
avoid the lookup when we already know the corresponding llvm global value.
llvm-svn: 196789
Before this patch GetOrCreateLLVMFunction would add a decl to
DeferredDeclsToEmit even when it was being called by the function trying to
emit that decl.
llvm-svn: 196753
This is a small optimization on linux, but should help more on windows
where msvc only outputs one destructor if there would be two identical ones.
llvm-svn: 194095
With this patch we produce alias for cases like
template<typename T>
struct foobar {
foobar() {
}
};
template struct foobar<void>;
We just have to be careful to produce the same aliases in every TU because
of comdats.
llvm-svn: 194000
This is a fixed version of r193161. In order to handle
void foo() __attribute__((alias("bar")));
void bar() {}
void zed() __attribute__((alias("foo")));
it is not enough to delay aliases to the end of the TU, we have to do two
passes over them to find if they are defined or not.
This can be implemented by producing alias as we go and just doing the second
pass at the end. This has the advantage that other parts of clang that were
expecting alias to be processed in order don't have to be changed.
This patch also handles cyclic aliases.
llvm-svn: 193188
This reverts commit r193161.
It broke
void foo() __attribute__((alias("bar")));
void bar() {}
void zed() __attribute__((alias("foo")));
Looks like we have to fix pr17639 first :-(
llvm-svn: 193162
names. For example, with this patch we now reject
void f1(void) __attribute__((alias("g1")));
This patch is implemented in CodeGen. It is quiet a bit simpler and more
compatible with gcc than implementing it in Sema. The downside is that the
errors only fire during -emit-llvm.
llvm-svn: 193161
Refactor the underlying code a bit to remove unnecessary calls to
"hasErrorOccurred" & make them consistently at all the entry points to
the IRGen ASTConsumer.
llvm-svn: 188707
Based on Peter Collingbourne's destructor patches.
Prior to this change, clang was considering ?1 to be the complete
destructor and the base destructor, which was wrong. This lead to
crashes when clang tried to emit two LLVM functions with the same name.
In this ABI, TUs with non-inline dtors might not emit a complete
destructor. They are emitted as inline thunks in TUs that need them,
and they always delegate to the base dtors of the complete class and its
virtual bases. This change uses the DeferredDecls machinery to emit
complete dtors as needed.
Currently in clang try body destructors can catch exceptions thrown by
virtual base destructors. In the Microsoft C++ ABI, clang may not have
the destructor definition, in which case clang won't wrap the virtual
virtual base destructor calls in a try-catch. Diagnosing this in user
code is TODO.
Finally, for classes that don't use virtual inheritance, MSVC always
calls the base destructor (?1) directly. This is a useful code size
optimization that avoids emitting lots of extra thunks or aliases.
Implementing it also means our existing tests continue to pass, and is
consistent with MSVC's output.
We can do the same for Itanium by tweaking GetAddrOfCXXDestructor, but
it will require further testing.
Reviewers: rjmccall
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1066
llvm-svn: 186828
The key insight here is that weak linkage for a static local variable
should always mean linkonce_odr, because every file that needs it will
generate a definition. We don't actually care about the precise linkage
of the parent context. I feel a bit silly that I didn't realize this before.
llvm-svn: 185381
Blocks, like lambdas, can be written in contexts which are required to be
treated as the same under ODR. Unlike lambdas, it isn't possible to actually
take the address of a block, so the mangling of the block itself doesn't
matter. However, objects like static variables inside a block do need to
be mangled in a consistent way.
There are basically three components here. One, block literals need a
consistent numbering. Two, objects/types inside a block literal need
to be mangled using it. Three, objects/types inside a block literal need
to have their linkage computed correctly.
llvm-svn: 185372
Introduce CXXStdInitializerListExpr node, representing the implicit
construction of a std::initializer_list<T> object from its underlying array.
The AST representation of such an expression goes from an InitListExpr with a
flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr
containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr).
This more detailed representation has several advantages, the most important of
which is that the new MaterializeTemporaryExpr allows us to directly model
lifetime extension of the underlying temporary array. Using that, this patch
*drastically* simplifies the IR generation of this construct, provides IR
generation support for nested global initializer_list objects, fixes several
bugs where the destructors for the underlying array would accidentally not get
invoked, and provides constant expression evaluation support for
std::initializer_list objects.
llvm-svn: 183872
handle temporaries which have been lifetime-extended to static storage duration
within constant expressions. This correctly handles nested lifetime extension
(through reference members of aggregates in aggregate initializers) but
non-constant-expression emission hasn't yet been updated to do the same.
llvm-svn: 183283
for C++ constructors.
If the DIType for a class was generated by
CGDebugInfo::createContextChain(), the cache contains only a
limited DIType wihtout any declarations. Since EmitFunctionStart()
needs to find the canonical declaration for each method, we
construct the complete type before emitting any method.
rdar://problem/13116508
llvm-svn: 181561
Summary:
Most of this change is wiring the pragma all the way through from the
lexer, parser, and sema to codegen. I considered adding a Decl AST node
for this, but it seemed too heavyweight.
Mach-O already uses a metadata flag called "Linker Options" to do this
kind of auto-linking. This change follows that pattern.
LLVM knows how to forward the "Linker Options" metadata into the COFF
.drectve section where these flags belong. ELF support is not
implemented, but possible.
This is related to auto-linking, which is http://llvm.org/PR13016.
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D723
llvm-svn: 181426
This patch adds a new common code feature that allows platform code to
request minimum alignment of global symbols. The background for this is
that on SystemZ, the most efficient way to load addresses of global symbol
is the LOAD ADDRESS RELATIVE LONG (LARL) instruction. This instruction
provides PC-relative addressing, but only to *even* addresses. For this
reason, existing compilers will guarantee that global symbols are always
aligned to at least 2. [ Since symbols would otherwise already use a
default alignment based on their type, this will usually only affect global
objects of character type or character arrays. ] GCC also allows creating
symbols without that extra alignment by using explicit "aligned" attributes
(which then need to be used on both definition and each use of the symbol).
To enable support for this with Clang, this patch adds a
TargetInfo::MinGlobalAlign variable that provides a global minimum for the
alignment of every global object (unless overridden via explicit alignment
attribute), and adds code to respect this setting. Within this patch, no
platform actually sets the value to anything but the default 1, resulting
in no change in behaviour on any existing target.
This version of the patch incorporates feedback from reviews by
Eric Christopher and John McCall. Thanks to all reviewers!
Patch by Richard Sandiford.
llvm-svn: 181210
Original commit message:
Emit the TLS intialization functions into a list.
Add the TLS initialization functions to a list of initialization functions. The
back-end takes this list and places the function pointers into the correct
section. This way they're called before `main().'
<rdar://problem/13733006>
llvm-svn: 180809
Add the TLS initialization functions to a list of initialization functions. The
back-end takes this list and places the function pointers into the correct
section. This way they're called before `main().'
<rdar://problem/13733006>
llvm-svn: 180739
