| #
c2d2b425 |
| 15-Oct-2015 |
Benjamin Kramer <[email protected]> |
[CodeGen] Remove dead code. NFC.
llvm-svn: 250418
|
| #
aec6b2c2 |
| 08-Oct-2015 |
Akira Hatanaka <[email protected]> |
[CodeGen] [CodeGen] Attach function attributes to functions created in CGBlocks.cpp.
This commit fixes a bug in clang's code-gen where it creates the following functions but doesn't attach function
[CodeGen] [CodeGen] Attach function attributes to functions created in CGBlocks.cpp.
This commit fixes a bug in clang's code-gen where it creates the following functions but doesn't attach function attributes to them:
__copy_helper_block_ __destroy_helper_block_ __Block_byref_object_copy_ __Block_byref_object_dispose_
rdar://problem/20828324
Differential Revision: http://reviews.llvm.org/D13525
llvm-svn: 249735
show more ...
|
| #
200500d6 |
| 08-Oct-2015 |
Akira Hatanaka <[email protected]> |
[CodeGen] Check if the Decl pointer passed is null, and if so, return early.
This is needed in a patch I plan to commit later, in which a null Decl pointer is passed to SetLLVMFunctionAttributesForD
[CodeGen] Check if the Decl pointer passed is null, and if so, return early.
This is needed in a patch I plan to commit later, in which a null Decl pointer is passed to SetLLVMFunctionAttributesForDefinition.
Relevant discussion is in http://reviews.llvm.org/D13525.
llvm-svn: 249722
show more ...
|
| #
3f02150d |
| 08-Oct-2015 |
David Majnemer <[email protected]> |
[MSVC Compat] Enable ABI impacting non-conforming behavior independently of -fms-compatibility
No ABI for C++ currently makes it possible to implement the standard 100% perfectly. We wrongly hid so
[MSVC Compat] Enable ABI impacting non-conforming behavior independently of -fms-compatibility
No ABI for C++ currently makes it possible to implement the standard 100% perfectly. We wrongly hid some of our compatible behavior behind -fms-compatibility instead of tying it to the compiler ABI.
llvm-svn: 249656
show more ...
|
| #
ed1fe5d0 |
| 03-Oct-2015 |
Yaron Keren <[email protected]> |
Replace double-negated !SourceLocation.isInvalid() with SourceLocation.isValid().
llvm-svn: 249228
|
| #
c005cc06 |
| 27-Sep-2015 |
Craig Topper <[email protected]> |
Use llvm::makeArrayRef. NFC.
llvm-svn: 248678
|
| #
510d7c71 |
| 21-Sep-2015 |
Akira Hatanaka <[email protected]> |
Remove attributes minsize and optsize, which conflict with optnone.
This commit fixes an assert that is triggered when optnone is being added to an IR function that is already marked with minsize an
Remove attributes minsize and optsize, which conflict with optnone.
This commit fixes an assert that is triggered when optnone is being added to an IR function that is already marked with minsize and optsize.
rdar://problem/22723716
Differential Revision: http://reviews.llvm.org/D13004
llvm-svn: 248191
show more ...
|
| #
b8327868 |
| 17-Sep-2015 |
Piotr Padlewski <[email protected]> |
Using MD_invariant_group
http://reviews.llvm.org/D12927
llvm-svn: 247933
|
| #
10aa7703 |
| 16-Sep-2015 |
Reid Kleckner <[email protected]> |
[WinEH] Pass the catch adjectives to catchpad directly
This avoids building a fake LLVM IR global variable just to ferry an i32 down into LLVM codegen. It also puts a nail in the coffin of using MS
[WinEH] Pass the catch adjectives to catchpad directly
This avoids building a fake LLVM IR global variable just to ferry an i32 down into LLVM codegen. It also puts a nail in the coffin of using MS ABI C++ EH with landingpads, since now we'll assert in the lpad code when flags are present.
llvm-svn: 247843
show more ...
|
| #
4b1ac72c |
| 15-Sep-2015 |
Piotr Padlewski <[email protected]> |
Decorating vptr load & stores with !invariant.group
Adding !invariant.group to vptr load/stores for devirtualization purposes. For more goto: http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227
Decorating vptr load & stores with !invariant.group
Adding !invariant.group to vptr load/stores for devirtualization purposes. For more goto: http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html
http://reviews.llvm.org/D12026
llvm-svn: 247725
show more ...
|
| #
9d0ecf27 |
| 15-Sep-2015 |
Piotr Padlewski <[email protected]> |
Added llvm.module flag for strict vtable pointers
It is dangerous to do LTO on code with strict-vtable-pointers, because one module has invariant.group.barriers, and the other one not.
In the futur
Added llvm.module flag for strict vtable pointers
It is dangerous to do LTO on code with strict-vtable-pointers, because one module has invariant.group.barriers, and the other one not.
In the future I want to just strip all invariant.group metadata from vptrs loads/stores and get rid of invariant.group.barrier calls.
http://reviews.llvm.org/D12580
llvm-svn: 247724
show more ...
|
| #
6b2a61d3 |
| 14-Sep-2015 |
Evgeniy Stepanov <[email protected]> |
Revert "Always_inline codegen rewrite" and 2 follow-ups.
Revert "Update cxx-irgen.cpp test to allow signext in alwaysinline functions." Revert "[CodeGen] Remove wrapper-free always_inline functions
Revert "Always_inline codegen rewrite" and 2 follow-ups.
Revert "Update cxx-irgen.cpp test to allow signext in alwaysinline functions." Revert "[CodeGen] Remove wrapper-free always_inline functions from COMDATs" Revert "Always_inline codegen rewrite."
Reason for revert: PR24793.
llvm-svn: 247620
show more ...
|
| #
2a791d7d |
| 14-Sep-2015 |
David Blaikie <[email protected]> |
[opaque pointer type] Fix a few uses of PointerType::getElementType in favor of uses of types already available elsewhere
These are a few cleanups I happened to have from trying to go in a different
[opaque pointer type] Fix a few uses of PointerType::getElementType in favor of uses of types already available elsewhere
These are a few cleanups I happened to have from trying to go in a different direction recently, so just flushing them out while I have them.
llvm-svn: 247593
show more ...
|
| #
aff29d30 |
| 14-Sep-2015 |
David Blaikie <[email protected]> |
Revert "[opaque pointer type] update for LLVM API change"
This was the wrong direction to take anyway (because ultimately the GlobalValue needed the pointee type again and /it/ used PointerType::get
Revert "[opaque pointer type] update for LLVM API change"
This was the wrong direction to take anyway (because ultimately the GlobalValue needed the pointee type again and /it/ used PointerType::getElementType eventually anyway)... let's go a different way.
This reverts commit r236161.
llvm-svn: 247586
show more ...
|
| #
67cb9740 |
| 12-Sep-2015 |
David Majnemer <[email protected]> |
[CodeGen] Remove wrapper-free always_inline functions from COMDATs
always_inline functions without a wrapper don't need to be in a COMDAT.
llvm-svn: 247500
|
| #
93db40a1 |
| 12-Sep-2015 |
Evgeniy Stepanov <[email protected]> |
Always_inline codegen rewrite.
Current implementation may end up emitting an undefined reference for an "inline __attribute__((always_inline))" function by generating an "available_externally always
Always_inline codegen rewrite.
Current implementation may end up emitting an undefined reference for an "inline __attribute__((always_inline))" function by generating an "available_externally alwaysinline" IR function for it and then failing to inline all the calls. This happens when a call to such function is in dead code. As the inliner is an SCC pass, it does not process dead code.
Libc++ relies on the compiler never emitting such undefined reference.
With this patch, we emit a pair of 1. internal alwaysinline definition (called F.alwaysinline) 2a. A stub F() { musttail call F.alwaysinline } -- or, depending on the linkage -- 2b. A declaration of F.
The frontend ensures that F.inlinefunction is only used for direct calls, and the stub is used for everything else (taking the address of the function, really). Declaration (2b) is emitted in the case when "inline" is meant for inlining only (like __gnu_inline__ and some other cases).
This approach, among other nice properties, ensures that alwaysinline functions are always internal, making it impossible for a direct call to such function to produce an undefined symbol reference.
This patch is based on ideas by Chandler Carruth and Richard Smith.
llvm-svn: 247494
show more ...
|
| #
67037ee2 |
| 11-Sep-2015 |
Evgeniy Stepanov <[email protected]> |
Revert "Specify target triple in alwaysinline tests." Revert "Always_inline codegen rewrite."
Breaks gdb & lldb tests. Breaks on Fedora 22 x86_64.
llvm-svn: 247491
|
| #
072e8350 |
| 11-Sep-2015 |
Evgeniy Stepanov <[email protected]> |
Always_inline codegen rewrite.
Current implementation may end up emitting an undefined reference for an "inline __attribute__((always_inline))" function by generating an "available_externally always
Always_inline codegen rewrite.
Current implementation may end up emitting an undefined reference for an "inline __attribute__((always_inline))" function by generating an "available_externally alwaysinline" IR function for it and then failing to inline all the calls. This happens when a call to such function is in dead code. As the inliner is an SCC pass, it does not process dead code.
Libc++ relies on the compiler never emitting such undefined reference.
With this patch, we emit a pair of 1. internal alwaysinline definition (called F.alwaysinline) 2a. A stub F() { musttail call F.alwaysinline } -- or, depending on the linkage -- 2b. A declaration of F.
The frontend ensures that F.inlinefunction is only used for direct calls, and the stub is used for everything else (taking the address of the function, really). Declaration (2b) is emitted in the case when "inline" is meant for inlining only (like __gnu_inline__ and some other cases).
This approach, among other nice properties, ensures that alwaysinline functions are always internal, making it impossible for a direct call to such function to produce an undefined symbol reference.
This patch is based on ideas by Chandler Carruth and Richard Smith.
llvm-svn: 247465
show more ...
|
| #
da1851ca |
| 10-Sep-2015 |
Artem Belevich <[email protected]> |
[CUDA] Allow trivial constructors as initializer for __shared__ variables.
Differential Revision: http://reviews.llvm.org/D12739
llvm-svn: 247307
|
| #
2c7f7e31 |
| 10-Sep-2015 |
Peter Collingbourne <[email protected]> |
CFI: Introduce -fsanitize=cfi-icall flag.
This flag causes the compiler to emit bit set entries for functions as well as runtime bitset checks at indirect call sites. Depends on the new function bit
CFI: Introduce -fsanitize=cfi-icall flag.
This flag causes the compiler to emit bit set entries for functions as well as runtime bitset checks at indirect call sites. Depends on the new function bitset mechanism.
Differential Revision: http://reviews.llvm.org/D11857
llvm-svn: 247238
show more ...
|
| #
25a80bf9 |
| 08-Sep-2015 |
Peter Collingbourne <[email protected]> |
CodeGen: Introduce CodeGenModule::CreateMetadataIdentifierForType.
This function can be used to create a metadata identifier for a specific type. No functionality change, but this will be used by D1
CodeGen: Introduce CodeGenModule::CreateMetadataIdentifierForType.
This function can be used to create a metadata identifier for a specific type. No functionality change, but this will be used by D11857 and D12026.
Differential Revision: http://reviews.llvm.org/D12038
llvm-svn: 247098
show more ...
|
| #
7f416cc4 |
| 08-Sep-2015 |
John McCall <[email protected]> |
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. C
Compute and preserve alignment more faithfully in IR-generation.
Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information.
As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter.
The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment.
Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset.
We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min.
Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize.
ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch.
I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually.
llvm-svn: 246985
show more ...
|
| #
0e2b975e |
| 04-Sep-2015 |
Hal Finkel <[email protected]> |
Don't crash on a self-alias declaration
We were crashing in CodeGen given input like this:
int self_alias(void) __attribute__((weak, alias("self_alias")));
such a self-alias is invalid, but inst
Don't crash on a self-alias declaration
We were crashing in CodeGen given input like this:
int self_alias(void) __attribute__((weak, alias("self_alias")));
such a self-alias is invalid, but instead of diagnosing the situation, we'd proceed to produce IR for both the function declaration and the alias. Because we already had a function named 'self_alias', the alias could not be named the same thing, and so LLVM would pick a different name ('self_alias1' for example) for that value. When we later called CodeGenModule::checkAliases, we'd look up the IR value corresponding to the alias name, find the function declaration instead, and then assert in a cast to llvm::GlobalAlias. The easiest way to prevent this is simply to avoid creating the wrongly-named alias value in the first place and issue the diagnostic there (instead of in checkAliases). We detect a related cycle case in CodeGenModule::EmitAliasDefinition already, so this just adds a second such check.
Even though the other test cases for this 'alias definition is part of a cycle' diagnostic are in test/Sema/attr-alias-elf.c, I've added a separate regression test for this case. This is because I can't add this check to test/Sema/attr-alias-elf.c without disturbing the other test cases in that file. In order to avoid construction of the bad IR values, this diagnostic is emitted from within CodeGenModule::EmitAliasDefinition (and the relevant declaration is not added to the Aliases vector). The other cycle checks are done within the CodeGenModule::checkAliases function based on the Aliases vector, called from CodeGenModule::Release. However, if there have been errors earlier, HandleTranslationUnit does not call Release, and so checkAliases is never called, and so none of the other diagnostics would be produced.
Fixes PR23509.
llvm-svn: 246882
show more ...
|
| #
c285307e |
| 03-Sep-2015 |
Dan Gohman <[email protected]> |
[WebAssembly] Initial WebAssembly support in clang
This implements basic support for compiling (though not yet assembling or linking) for a WebAssembly target. Note that ABI details are not yet fina
[WebAssembly] Initial WebAssembly support in clang
This implements basic support for compiling (though not yet assembling or linking) for a WebAssembly target. Note that ABI details are not yet finalized, and may change.
Differential Revision: http://reviews.llvm.org/D12002
llvm-svn: 246814
show more ...
|
| #
cab5858e |
| 31-Aug-2015 |
Andrey Bokhanko <[email protected]> |
PR17829: Proper diagnostic of mangled names conflicts
Proper diagnostic and resolution of mangled names conflicts between C++ methods and C functions. This patch implements support for functions/met
PR17829: Proper diagnostic of mangled names conflicts
Proper diagnostic and resolution of mangled names conflicts between C++ methods and C functions. This patch implements support for functions/methods only; support for variables is coming separately.
Differential Revision: http://reviews.llvm.org/D11297
llvm-svn: 246438
show more ...
|