#
b8327868 |
| 17-Sep-2015 |
Piotr Padlewski <prazek@google.com> |
Using MD_invariant_group
http://reviews.llvm.org/D12927
llvm-svn: 247933
|
#
10aa7703 |
| 16-Sep-2015 |
Reid Kleckner <rnk@google.com> |
[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 <prazek@google.com> |
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 <prazek@google.com> |
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 <eugeni.stepanov@gmail.com> |
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 <dblaikie@gmail.com> |
[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 <dblaikie@gmail.com> |
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 <david.majnemer@gmail.com> |
[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 <eugeni.stepanov@gmail.com> |
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 <eugeni.stepanov@gmail.com> |
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 <eugeni.stepanov@gmail.com> |
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 <tra@google.com> |
[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 <peter@pcc.me.uk> |
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 <peter@pcc.me.uk> |
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 <rjmccall@apple.com> |
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 <hfinkel@anl.gov> |
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 <dan433584@gmail.com> |
[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 <andreybokhanko@gmail.com> |
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 ...
|
#
6eaa8323 |
| 28-Aug-2015 |
Hans Wennborg <hans@hanshq.net> |
Allow TLS vars in dllimport/export functions; only inline dllimport functions when safe (PR24593)
This patch does two things:
1) Don't error about dllimport/export on thread-local static local vari
Allow TLS vars in dllimport/export functions; only inline dllimport functions when safe (PR24593)
This patch does two things:
1) Don't error about dllimport/export on thread-local static local variables. We put those attributes on static locals in dllimport/export functions implicitly in case the function gets inlined. Now, for TLS variables this is a problem because we can't import such variables, but it's a benign problem becase:
2) Make sure we never inline a dllimport function TLS static locals. In fact, never inline a dllimport function that references a non-imported function or variable (because these are not defined in the importing library). This seems to match MSVC's behaviour.
Differential Revision: http://reviews.llvm.org/D12422
llvm-svn: 246338
show more ...
|
Revision tags: llvmorg-3.7.0, llvmorg-3.7.0-rc4 |
|
#
284ebe23 |
| 22-Aug-2015 |
Jingyue Wu <jingyue@google.com> |
[CUDA] Change initializer for CUDA device code based on CUDA documentation.
Summary: According to CUDA documentation, global variables declared with __device__, __constant__ can be initialized from
[CUDA] Change initializer for CUDA device code based on CUDA documentation.
Summary: According to CUDA documentation, global variables declared with __device__, __constant__ can be initialized from host code, so mark them as externally initialized. Because __shared__ variables cannot have an initialization as part of their declaration and since the value maybe kept across different kernel invocation, the value of __shared__ is effectively undefined instead of zero initialized.
Wrongly using zero initializer may cause illegitimate optimization, e.g. removing unused __constant__ variable because it's not updated in the device code and the value is initialized with zero.
Test Plan: test/CodeGenCUDA/address-spaces.cu
Patch by Xuetian Weng
Reviewers: jholewinski, eliben, tra, jingyue
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D12241
llvm-svn: 245786
show more ...
|
Revision tags: llvmorg-3.7.0-rc3 |
|
#
c52efa7d |
| 19-Aug-2015 |
Richard Smith <richard-llvm@metafoo.co.uk> |
[modules] Don't eagerly deserialize so many ImportDecls. CodeGen basically ignores ImportDecls imported from modules, so only eagerly deserialize the ones from a PCH / preamble.
llvm-svn: 245406
|
#
2dcef9e0 |
| 13-Aug-2015 |
David Majnemer <david.majnemer@gmail.com> |
Avoid iteration invalidation issues around MaterializedTemporaryExpr
We risk iterator invalidation issues if we use a DenseMap to hold the backing storage for an APValue. Instead, BumpPtrAllocate t
Avoid iteration invalidation issues around MaterializedTemporaryExpr
We risk iterator invalidation issues if we use a DenseMap to hold the backing storage for an APValue. Instead, BumpPtrAllocate them and use APValue * as our DenseMap value.
Also, don't assume that MaterializedGlobalTemporaryMap won't regrow between when we initially perform a lookup and later on when we actually try to insert into it.
This fixes PR24289.
Differential Revision: http://reviews.llvm.org/D11629
llvm-svn: 244989
show more ...
|
Revision tags: studio-1.4 |
|
#
556b21aa |
| 13-Aug-2015 |
Yaron Keren <yaron.keren@gmail.com> |
Remove and forbid raw_svector_ostream::flush() calls. After r244870 flush() will only compare two null pointers and return, doing nothing but wasting run time. The call is not required any more as th
Remove and forbid raw_svector_ostream::flush() calls. After r244870 flush() will only compare two null pointers and return, doing nothing but wasting run time. The call is not required any more as the stream and its SmallString are always in sync.
Thanks to David Blaikie for reviewing.
llvm-svn: 244928
show more ...
|
#
02d5d86b |
| 06-Aug-2015 |
Eric Christopher <echristo@gmail.com> |
Rename the non-coding style conformant functions in namespace Builtins to match the rest of their brethren and reformat the bits that need it.
llvm-svn: 244186
|
#
124955aa |
| 05-Aug-2015 |
Reid Kleckner <reid@kleckner.net> |
Add -gcodeview and -gdwarf to control which type Clang emits
Summary: By default, 'clang' emits dwarf and 'clang-cl' emits codeview. You can force emission of one or both by passing -gcodeview and
Add -gcodeview and -gdwarf to control which type Clang emits
Summary: By default, 'clang' emits dwarf and 'clang-cl' emits codeview. You can force emission of one or both by passing -gcodeview and -gdwarf to either driver.
Reviewers: dblaikie, hans
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D11742
llvm-svn: 244097
show more ...
|