| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
This reverts commit r204783.
llvm-svn: 204785
|
|
|
|
| |
llvm-svn: 204783
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 204596
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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!
llvm-svn: 204586
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
propimpl_end() with iterator_range property_impls(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203930
|
|
|
|
|
|
| |
with iterator_range methods(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203832
|
|
|
|
| |
llvm-svn: 203804
|
|
|
|
|
|
|
|
|
| |
I've clearly done something wrong with how to get this to link
correctly. Reverting for now.
This reverts commit r203711.
llvm-svn: 203712
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
specific_attr_end() with iterator_range specific_attrs(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203474
|
|
|
|
|
|
|
|
|
| |
r203364: what was use_iterator is now user_iterator, and there is
a use_iterator for directly iterating over the uses.
This also switches to use the range-based APIs where appropriate.
llvm-svn: 203365
|
|
|
|
|
|
| |
iterator_range decls(). The same is true for the noload versions of these APIs. Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203278
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
LLVM r202816.
llvm-svn: 202817
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
explicit instantiation declaration (& always emit such a type when there's an explicit instantiation definition)
We should only have this optimization fire when the explicit
instantiation definition would cause at least one member function to be
emitted, thus ensuring that even a compiler not performing this
optimization would still emit the full type information elsewhere.
But we should also pessimize output still by always emitting the
definition when the explicit instantiation definition appears so that at
some point in the future we can depend on that information even when no
code had to be emitted in that TU. (this shouldn't happen very often,
since people mostly use explicit spec decl/defs to reduce code size -
but perhaps one day they could use it to explicitly reduce debug info
size too)
This was worth about 2% for Clang and LLVM - so not a huge win, but a
win. It looks really great for simple STL programs (include <string> and
just declare a string - 14k -> 1.4k of .dwo)
llvm-svn: 202769
|
|
|
|
|
|
|
|
|
|
| |
The __forceinline keyword's semantics are now recast as AlwaysInline and
the kw___forceinline token has its language mode set for KEYMS.
This preserves the semantics of the previous implementation but with
less duplication of code.
llvm-svn: 202131
|
|
|
|
|
|
|
|
| |
that the optimizer does not duplicate code.
Patch thanks to Marcello Maggioni!
llvm-svn: 201941
|
|
|
|
| |
llvm-svn: 201470
|
|
|
|
|
|
|
|
| |
Xcore target ABI requires const data that is externally visible
to be handled differently if it has C-language linkage rather than
C++ language linkage.
llvm-svn: 201142
|
|
|
|
|
|
|
|
|
|
| |
This option has the following effects:
* It adds the sspstrong IR attribute to each function within the CU.
* It defines the macro __SSP_STRONG__ with the value of 2.
Differential Revision: http://llvm-reviews.chandlerc.com/D2717
llvm-svn: 201120
|
|
|
|
|
|
| |
gross, and increasingly replaced through other mechanisms.
llvm-svn: 201011
|
|
|
|
| |
llvm-svn: 200711
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace the last incorrect uses and templatize the function to require a
compile-time constant string preventing further misuse.
The diagnostic formatter expects well-formed input and has undefined behaviour
with arbitrary input or crafted user strings in source files. Accepting user
input would also have caused unbounded generation of new diagnostic IDs which
can be problematic in long-running sessions or language bindings.
This completes the work to fix several incorrect callers that passed user
input or raw messages to the diagnostics engine where a constant format string
was expected.
llvm-svn: 200132
|
|
|
|
| |
llvm-svn: 199709
|
|
|
|
| |
llvm-svn: 199705
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without them they can be merged with non unnamed_addr constants during LTO.
The resulting constant is not unnamed_addr and goes in a different section,
which causes ld64 to crash.
A testcase that would crash before:
* file1.mm:
void g(id notification) {
[notification valueForKey:@"name"];
}
* file2.cpp:
extern const char js_name_str[] = "name";
* file3.cpp
extern bool JS_GetProperty(const char *name);
extern const char js_name_str[];
bool js_ReportUncaughtException() { JS_GetProperty(js_name_str); }
run
clang file1.mm -o file1.o -c -w -emit-llvm
clang file2.cpp -o file2.o -c -w -emit-llvm
clang file3.cpp -o file3.o -c -w
ld -dylib -o XUL file1.o file2.o file3.o -undefined dynamic_lookup.
llvm-svn: 199688
|
|
|
|
|
|
| |
Thanks to David Blaikie for the push.
llvm-svn: 199685
|
|
|
|
| |
llvm-svn: 199665
|
|
|
|
|
|
|
| |
With the old linkage types removed, set the linkage to external for both
dllimport and dllexport to reflect what's currently supported.
llvm-svn: 199220
|
|
|
|
| |
llvm-svn: 198692
|
|
|
|
|
|
|
| |
encodes the canonical rules for LLVM's style. I noticed this had drifted
quite a bit when cleaning up LLVM, so wanted to clean up Clang as well.
llvm-svn: 198686
|
|
|
|
| |
llvm-svn: 198640
|
|
|
|
|
|
|
|
|
|
| |
'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
|
|
|
|
|
|
|
|
| |
directly and check the resulting value.
No functional changes intended.
llvm-svn: 197652
|
|
|
|
|
|
| |
change intended -- this only replaces Boolean uses of getAttr.
llvm-svn: 197648
|
|
|
|
|
|
|
|
| |
Tidy up built-in record creation to reduce code duplication.
Continuation of r197336.
llvm-svn: 197452
|
|
|
|
|
|
|
|
|
|
| |
We were mistakengly giving linkonce_odr linkage instead of internal
linkage to the deleting and complete destructor thunks for classes in
anonymous namespaces.
Fixes PR17273.
llvm-svn: 197060
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
We can reuse it to avoid a DenseMap+StringMap lookup to find if it was already
emitted or not.
This fixes a 2010 TODO.
llvm-svn: 196785
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 196727
|
|
|
|
|
|
|
| |
Suggested by Eric.
Paired commit with r196144.
llvm-svn: 196145
|
|
|
|
| |
llvm-svn: 196143
|
|
|
|
|
|
|
|
| |
emit an error instead of asserting.
rdar://15522601 & http://llvm.org/PR18031
llvm-svn: 195556
|
|
|
|
|
|
|
|
| |
info version number.
Will error out when modules have different version numbers.
llvm-svn: 195495
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
static data members with inline initializers (PR17689)
This makes Clang emit a linkonce_odr definition for 'val' in the code below,
to be compatible with MSVC-compiled code:
struct Foo {
static const int val = 1;
};
Differential Revision: http://llvm-reviews.chandlerc.com/D2233
llvm-svn: 195283
|
|
|
|
|
|
| |
Bitcasts between address spaces are no longer allowed.
llvm-svn: 194765
|
|
|
|
| |
llvm-svn: 194717
|