Initializers of global data that can appear multiple TUs (static data
members of class templates or __declspec(selectany) data) are now in a
comdat group keyed on the global variable being initialized. On
non-Windows platforms, this is a code size and startup time
optimization. On Windows, this is necessary for ABI compatibility with
MSVC.
Fixes PR16959.
Reviewers: rsmith
Differential Revision: http://reviews.llvm.org/D3811
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209555 91177308-0d34-0410-b5e6-96231b3b80d8
This was fairly broken. For example,
@__dso_handle would or would not get an unnamed_addr depending on how many
global destructors were used in a translation unit.
The consensus was that not every runtime variable is unnamed_addr and that
__dso_handle handle should not be, so just don't add unnamed_addr in
CreateRuntimeVariable.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209484 91177308-0d34-0410-b5e6-96231b3b80d8
behavior on mismatch. The AutoUpgrader will drop incompatible debug info
any way and also emit a warning diagnostic for it.
rdar://problem/16926122
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209182 91177308-0d34-0410-b5e6-96231b3b80d8
Now that llvm cannot represent alias cycles, we have to diagnose erros just
before trying to close the cycle. This degrades the errors a bit. The real
solution is what it was before: if we want to provide good errors for these
cases, we have to be able to find a clang level decl given a mangled name
and produce the error from Sema.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@209008 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Previously, we would generate a single name for all reference
temporaries and allow LLVM to rename them for us. Instead, number the
reference temporaries as we build them in Sema.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3554
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@207776 91177308-0d34-0410-b5e6-96231b3b80d8
Reference temporaries inherited many properties from the variable that
they correspond to but visibility wasn't one of them.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@207496 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
A reference temporary should inherit the linkage of the variable it
initializes. Otherwise, we may hit cases where a reference temporary
wouldn't have the same value in all translation units.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D3515
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@207451 91177308-0d34-0410-b5e6-96231b3b80d8
Almost all linkage calculation for VarDecls occured inside of
GetLLVMLinkageVarDefinition except for static data members. Centralize
the logic so that it can be more readily reused.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@207241 91177308-0d34-0410-b5e6-96231b3b80d8
It turns out that linkage and visibility have rather similar logic for
both functions and non-variable globals. Split the calculation out so
that both sides may share this code.
No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@207239 91177308-0d34-0410-b5e6-96231b3b80d8
Update clang to use the InstrProfReader from LLVM to read
instrumentation based profile data. This also switches us from the
naive text format to the binary format, since that's what's
implemented in the reader.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@206658 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@206322 91177308-0d34-0410-b5e6-96231b3b80d8
Emitting the PGO initialization in EmitGlobalFunctionDefinition is
inefficient, since this only has an effect once per module. We move
this to Release() with the rest of the once-per-module logic.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205977 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
MSVC always emits inline functions marked with the extern storage class
specifier. The result is something similar to the opposite of
__attribute__((gnu_inline)).
This extension is also available in C.
This fixes PR19264.
Reviewers: rnk, rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3207
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205485 91177308-0d34-0410-b5e6-96231b3b80d8
Clang implements the part of the ARM ABI saying that certain functions
(e.g., constructors and destructors) return "this", but Apple's version of
gcc and llvm-gcc did not. The libstdc++ dylib on iOS 5 was built with
llvm-gcc, which means that clang cannot safely assume that code from the C++
runtime will correctly follow the ABI. It is also possible to run into this
problem when linking with other libraries built with gcc or llvm-gcc. Even
though there is no way to reliably detect that situation, it is most likely
to come up when targeting older versions of iOS. Disabling the optimization
for any code targeting iOS 5 solves the libstdc++ problem and has a reasonably
good chance of fixing the issue for other older libraries as well.
<rdar://problem/16377159>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205272 91177308-0d34-0410-b5e6-96231b3b80d8
This adds Clang support for the ARM64 backend. There are definitely
still some rough edges, so please bring up any issues you see with
this patch.
As with the LLVM commit though, we think it'll be more useful for
merging with AArch64 from within the tree.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205100 91177308-0d34-0410-b5e6-96231b3b80d8
The peculiarities of C99 create scenario where an LLVM IR function
declaration may need to be replaced with a definition baring a different
type because the prototype and definition are not required to agree.
However, we were not properly deferring this when it occurred.
This fixes PR19280.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205099 91177308-0d34-0410-b5e6-96231b3b80d8
This produces valid IR now that llvm rejects aliases to weak aliases and warns
the user that the resolution is not changed if the weak alias is overridden.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204935 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204675 91177308-0d34-0410-b5e6-96231b3b80d8
This commit cleans up a few accidents:
- Do not rely on the order in which StringLiteral lays out bytes.
- Use a more efficient mechanism for handling so-called
"special-mappings" when mangling string literals.
- There is no need to allocate a copy of the mangled name.
- Add the test written for r204562.
Thanks to Richard Smith for pointing these out!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204586 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204562 91177308-0d34-0410-b5e6-96231b3b80d8
I've clearly done something wrong with how to get this to link
correctly. Reverting for now.
This reverts commit r203711.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203712 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203711 91177308-0d34-0410-b5e6-96231b3b80d8
Reid Kleckner