|
Revision tags: llvmorg-6.0.0-rc1 |
|
| #
f3b3ccda |
| 19-Dec-2017 |
Adrian Prantl <[email protected]> |
Silence a bunch of implicit fallthrough warnings
llvm-svn: 321115
|
|
Revision tags: llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2, llvmorg-5.0.1-rc1, llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3 |
|
| #
6cc8317c |
| 25-Aug-2017 |
Alex Lorenz <[email protected]> |
[IRGen] Evaluate constant static variables referenced through member expressions
C++ allows us to reference static variables through member expressions. Prior to this commit, non-integer static vari
[IRGen] Evaluate constant static variables referenced through member expressions
C++ allows us to reference static variables through member expressions. Prior to this commit, non-integer static variables that were referenced using a member expression were always emitted using lvalue loads. The old behaviour introduced an inconsistency between regular uses of static variables and member expressions uses. For example, the following program compiled and linked successfully:
struct Foo { constexpr static const char *name = "foo"; }; int main() { return Foo::name[0] == 'f'; }
but this program failed to link because "Foo::name" wasn't found:
struct Foo { constexpr static const char *name = "foo"; }; int main() { Foo f; return f.name[0] == 'f'; }
This commit ensures that constant static variables referenced through member expressions are emitted in the same way as ordinary static variable references.
rdar://33942261
Differential Revision: https://reviews.llvm.org/D36876
llvm-svn: 311772
show more ...
|
|
Revision tags: llvmorg-5.0.0-rc2, llvmorg-5.0.0-rc1, llvmorg-4.0.1, llvmorg-4.0.1-rc3, llvmorg-4.0.1-rc2 |
|
| #
72236372 |
| 11-May-2017 |
Richard Smith <[email protected]> |
PR22877: When constructing an array via a constructor with a default argument in list-initialization, run cleanups for the default argument after each iteration of the initialization loop.
We previo
PR22877: When constructing an array via a constructor with a default argument in list-initialization, run cleanups for the default argument after each iteration of the initialization loop.
We previously only ran the destructor for any temporary once, at the end of the complete loop, rather than once per iteration!
Re-commit of r302750, reverted in r302776.
llvm-svn: 302817
show more ...
|
| #
1f53d03a |
| 11-May-2017 |
Diana Picus <[email protected]> |
Revert "PR22877: When constructing an array via a constructor with a default argument in list-initialization, run cleanups for the default argument after each iteration of the initialization loop."
Revert "PR22877: When constructing an array via a constructor with a default argument in list-initialization, run cleanups for the default argument after each iteration of the initialization loop."
Revert "clang/test/CodeGenCXX/array-default-argument.cpp: Satisfy targets that have x86_thiscallcc."
This reverts commit r302750 and its fixup r302757 because the test is still breaking on some of the ARM bots.
array-default-argument.cpp:20:12: error: expected string not found in input // CHECK: {{call|invoke}}[[THISCALL:( x86_thiscallcc)?]] void @_ZN1AC1Ev([[TEMPORARY:.*]]) ^ <stdin>:18:1: note: scanning from here arrayctor.loop: ; preds = %arrayctor.loop, %entry ^ <stdin>:28:2: note: possible intended match here call void @_Z1fv() ^
--
llvm-svn: 302776
show more ...
|
| #
97a2cdbf |
| 11-May-2017 |
Richard Smith <[email protected]> |
PR22877: When constructing an array via a constructor with a default argument in list-initialization, run cleanups for the default argument after each iteration of the initialization loop.
We previo
PR22877: When constructing an array via a constructor with a default argument in list-initialization, run cleanups for the default argument after each iteration of the initialization loop.
We previously only ran the destructor for any temporary once, at the end of the complete loop, rather than once per iteration!
llvm-svn: 302750
show more ...
|
|
Revision tags: llvmorg-4.0.1-rc1 |
|
| #
2c51880a |
| 30-Mar-2017 |
Simon Pilgrim <[email protected]> |
Spelling mistakes in comments. NFCI. (PR27635)
llvm-svn: 299083
|
| #
5eb58583 |
| 26-Mar-2017 |
Gor Nishanov <[email protected]> |
[coroutines] Add codegen for await and yield expressions
Details:
Emit suspend expression which roughly looks like:
auto && x = CommonExpr(); if (!x.await_ready()) { llvm_coro_save(); x.awai
[coroutines] Add codegen for await and yield expressions
Details:
Emit suspend expression which roughly looks like:
auto && x = CommonExpr(); if (!x.await_ready()) { llvm_coro_save(); x.await_suspend(...); (*) llvm_coro_suspend(); (**) } x.await_resume(); where the result of the entire expression is the result of x.await_resume()
(*) If x.await_suspend return type is bool, it allows to veto a suspend: if (x.await_suspend(...)) llvm_coro_suspend(); (**) llvm_coro_suspend() encodes three possible continuations as a switch instruction:
%where-to = call i8 @llvm.coro.suspend(...) switch i8 %where-to, label %coro.ret [ ; jump to epilogue to suspend i8 0, label %yield.ready ; go here when resumed i8 1, label %yield.cleanup ; go here when destroyed ]
llvm-svn: 298784
show more ...
|
|
Revision tags: llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3, llvmorg-4.0.0-rc2, llvmorg-4.0.0-rc1 |
|
| #
89831421 |
| 23-Dec-2016 |
Egor Churaev <[email protected]> |
Fix problems in "[OpenCL] Enabling the usage of CLK_NULL_QUEUE as compare operand."
Summary: Fixed warnings in commit: https://reviews.llvm.org/rL290171
Reviewers: djasper, Anastasia
Subscribers:
Fix problems in "[OpenCL] Enabling the usage of CLK_NULL_QUEUE as compare operand."
Summary: Fixed warnings in commit: https://reviews.llvm.org/rL290171
Reviewers: djasper, Anastasia
Subscribers: yaxunl, cfe-commits, bader
Differential Revision: https://reviews.llvm.org/D27981
llvm-svn: 290431
show more ...
|
| #
9068938e |
| 20-Dec-2016 |
Daniel Jasper <[email protected]> |
Revert "[OpenCL] Enabling the usage of CLK_NULL_QUEUE as compare operand."
This reverts commit r290171. It triggers a bunch of warnings, because the new enumerator isn't handled in all switches. We
Revert "[OpenCL] Enabling the usage of CLK_NULL_QUEUE as compare operand."
This reverts commit r290171. It triggers a bunch of warnings, because the new enumerator isn't handled in all switches. We want a warning-free build.
Replied on the commit with more details.
llvm-svn: 290173
show more ...
|
| #
67c3f3ec |
| 20-Dec-2016 |
Egor Churaev <[email protected]> |
[OpenCL] Enabling the usage of CLK_NULL_QUEUE as compare operand.
Summary: Enabling the compression of CLK_NULL_QUEUE to variable of type queue_t.
Reviewers: Anastasia
Subscribers: cfe-commits, ya
[OpenCL] Enabling the usage of CLK_NULL_QUEUE as compare operand.
Summary: Enabling the compression of CLK_NULL_QUEUE to variable of type queue_t.
Reviewers: Anastasia
Subscribers: cfe-commits, yaxunl, bader
Differential Revision: https://reviews.llvm.org/D27569
llvm-svn: 290171
show more ...
|
| #
402804b6 |
| 15-Dec-2016 |
Yaxun Liu <[email protected]> |
Re-commit r289252 and r289285, and fix PR31374
llvm-svn: 289787
|
| #
7849eeb0 |
| 14-Dec-2016 |
Nico Weber <[email protected]> |
Revert 289252 (and follow-up 289285), it caused PR31374
llvm-svn: 289713
|
| #
939b6880 |
| 14-Dec-2016 |
Richard Smith <[email protected]> |
When emitting a multidimensional array copy, only emit a single flattened cleanup loop for exception handling.
llvm-svn: 289623
|
| #
30e304e2 |
| 14-Dec-2016 |
Richard Smith <[email protected]> |
Remove custom handling of array copies in lambda by-value array capture and copy constructors of classes with array members, instead using ArrayInitLoopExpr to represent the initialization loop.
Thi
Remove custom handling of array copies in lambda by-value array capture and copy constructors of classes with array members, instead using ArrayInitLoopExpr to represent the initialization loop.
This exposed a bug in the static analyzer where it was unable to differentiate between zero-initialized and unknown array values, which has also been fixed here.
llvm-svn: 289618
show more ...
|
| #
410306bf |
| 12-Dec-2016 |
Richard Smith <[email protected]> |
Add two new AST nodes to represent initialization of an array in terms of initialization of each array element:
* ArrayInitLoopExpr is a prvalue of array type with two subexpressions: a common e
Add two new AST nodes to represent initialization of an array in terms of initialization of each array element:
* ArrayInitLoopExpr is a prvalue of array type with two subexpressions: a common expression (an OpaqueValueExpr) that represents the up-front computation of the source of the initialization, and a subexpression representing a per-element initializer * ArrayInitIndexExpr is a prvalue of type size_t representing the current position in the loop
This will be used to replace the creation of explicit index variables in lambda capture of arrays and copy/move construction of classes with array elements, and also C++17 structured bindings of arrays by value (which inexplicably allow copying an array by value, unlike all of C++'s other array declarations).
No uses of these nodes are introduced by this change, however.
llvm-svn: 289413
show more ...
|
| #
8f66b4b4 |
| 09-Dec-2016 |
Yaxun Liu <[email protected]> |
Add support for non-zero null pointer for C and OpenCL
In amdgcn target, null pointers in global, constant, and generic address space take value 0 but null pointers in private and local address spac
Add support for non-zero null pointer for C and OpenCL
In amdgcn target, null pointers in global, constant, and generic address space take value 0 but null pointers in private and local address space take value -1. Currently LLVM assumes all null pointers take value 0, which results in incorrectly translated IR. To workaround this issue, instead of emit null pointers in local and private address space, a null pointer in generic address space is emitted and casted to local and private address space.
Tentative definition of global variables with non-zero initializer will have weak linkage instead of common linkage since common linkage requires zero initializer and does not have explicit section to hold the non-zero value.
Virtual member functions getNullPointer and performAddrSpaceCast are added to TargetCodeGenInfo which by default returns ConstantPointerNull and emitting addrspacecast instruction. A virtual member function getNullPointerValue is added to TargetInfo which by default returns 0. Each target can override these virtual functions to get target specific null pointer and the null pointer value for specific address space, and perform specific translations for addrspacecast.
Wrapper functions getNullPointer is added to CodegenModule and getTargetNullPointerValue is added to ASTContext to facilitate getting the target specific null pointers and their values.
This change has no effect on other targets except amdgcn target. Other targets can provide support of non-zero null pointer in a similar way.
This change only provides support for non-zero null pointer for C and OpenCL. Supporting for other languages will be added later incrementally.
Differential Revision: https://reviews.llvm.org/D26196
llvm-svn: 289252
show more ...
|
| #
122f88d4 |
| 06-Dec-2016 |
Richard Smith <[email protected]> |
[c++17] P0135R1: Guaranteed copy elision.
When an object of class type is initialized from a prvalue of the same type (ignoring cv qualifications), use the prvalue to initialize the object directly
[c++17] P0135R1: Guaranteed copy elision.
When an object of class type is initialized from a prvalue of the same type (ignoring cv qualifications), use the prvalue to initialize the object directly instead of inserting a redundant elidable call to a copy constructor.
llvm-svn: 288866
show more ...
|
|
Revision tags: llvmorg-3.9.1, llvmorg-3.9.1-rc3, llvmorg-3.9.1-rc2, llvmorg-3.9.1-rc1, llvmorg-3.9.0, llvmorg-3.9.0-rc3, llvmorg-3.9.0-rc2, llvmorg-3.9.0-rc1 |
|
| #
0bc4b2d3 |
| 28-Jul-2016 |
Yaxun Liu <[email protected]> |
[OpenCL] Generate opaque type for sampler_t and function call for the initializer
Currently Clang use int32 to represent sampler_t, which have been a source of issue for some backends, because in so
[OpenCL] Generate opaque type for sampler_t and function call for the initializer
Currently Clang use int32 to represent sampler_t, which have been a source of issue for some backends, because in some backends sampler_t cannot be represented by int32. They have to depend on kernel argument metadata and use IPA to find the sampler arguments and global variables and transform them to target specific sampler type.
This patch uses opaque pointer type opencl.sampler_t* for sampler_t. For each use of file-scope sampler variable, it generates a function call of __translate_sampler_initializer. For each initialization of function-scope sampler variable, it generates a function call of __translate_sampler_initializer.
Each builtin library can implement its own __translate_sampler_initializer(). Since the real sampler type tends to be architecture dependent, allowing it to be initialized by a library function simplifies backend design. A typical implementation of __translate_sampler_initializer could be a table lookup of real sampler literal values. Since its argument is always a literal, the returned pointer is known at compile time and easily optimized to finally become some literal values directly put into image read instructions.
This patch is partially based on Alexey Sotkin's work in Khronos Clang (https://github.com/KhronosGroup/SPIR/commit/3d4eec61623502fc306e8c67c9868be2b136e42b).
Differential Revision: https://reviews.llvm.org/D21567
llvm-svn: 277024
show more ...
|
| #
5179eb78 |
| 28-Jun-2016 |
Richard Smith <[email protected]> |
P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991:
Replace inheriting constructors implementation with new approach, voted into C++ last year as a DR against C++11.
Instead of
P0136R1, DR1573, DR1645, DR1715, DR1736, DR1903, DR1941, DR1959, DR1991:
Replace inheriting constructors implementation with new approach, voted into C++ last year as a DR against C++11.
Instead of synthesizing a set of derived class constructors for each inherited base class constructor, we make the constructors of the base class visible to constructor lookup in the derived class, using the normal rules for using-declarations.
For constructors, UsingShadowDecl now has a ConstructorUsingShadowDecl derived class that tracks the requisite additional information. We create shadow constructors (not found by name lookup) in the derived class to model the actual initialization, and have a new expression node, CXXInheritedCtorInitExpr, to model the initialization of a base class from such a constructor. (This initialization is special because it performs real perfect forwarding of arguments.)
In cases where argument forwarding is not possible (for inalloca calls, variadic calls, and calls with callee parameter cleanup), the shadow inheriting constructor is not emitted and instead we directly emit the initialization code into the caller of the inherited constructor.
Note that this new model is not perfectly compatible with the old model in some corner cases. In particular: * if B inherits a private constructor from A, and C uses that constructor to construct a B, then we previously required that A befriends B and B befriends C, but the new rules require A to befriend C directly, and * if a derived class has its own constructors (and so its implicit default constructor is suppressed), it may still inherit a default constructor from a base class
llvm-svn: 274049
show more ...
|
|
Revision tags: llvmorg-3.8.1, llvmorg-3.8.1-rc1 |
|
| #
6365e464 |
| 08-Mar-2016 |
Richard Smith <[email protected]> |
Fix -Werror build.
llvm-svn: 262965
|
| #
872307e2 |
| 08-Mar-2016 |
Richard Smith <[email protected]> |
P0017R1: In C++1z, an aggregate class can have (public non-virtual) base classes; these are initialized as if they were data members.
llvm-svn: 262963
|
|
Revision tags: llvmorg-3.8.0 |
|
| #
29b5f086 |
| 24-Feb-2016 |
James Y Knight <[email protected]> |
Default vaarg lowering should support indirect struct types.
Fixes PR11517 for SPARC.
On most targets, clang lowers va_arg itself, eschewing the use of the llvm vaarg instruction. This is necessary
Default vaarg lowering should support indirect struct types.
Fixes PR11517 for SPARC.
On most targets, clang lowers va_arg itself, eschewing the use of the llvm vaarg instruction. This is necessary (at least for now) as the type argument to the vaarg instruction cannot represent all the ABI information that is needed to support complex calling conventions.
However, on targets with a simpler varrags ABIs, the LLVM instruction can work just fine, and clang can simply lower to it. Unfortunately, even on such targets, vaarg with a struct argument would fail, because the default lowering to vaarg was naive: it didn't take into account the ABI attribute computed by classifyArgumentType. In particular, for the DefaultABIInfo, structs are supposed to be passed indirectly and so llvm's vaarg instruction should be emitted with a pointer argument.
Now, vaarg instruction emission is able to use computed ABIArgInfo for the provided argument type, which allows the default ABI support to work for structs too.
I haven't touched the EmitVAArg implementation for PPC32_SVR4 or XCore, although I believe both are now redundant, and could be switched over to use the default implementation as well.
Differential Revision: http://reviews.llvm.org/D16154
llvm-svn: 261717
show more ...
|
|
Revision tags: llvmorg-3.8.0-rc3, llvmorg-3.8.0-rc2, llvmorg-3.8.0-rc1 |
|
| #
df1ed009 |
| 13-Jan-2016 |
George Burgess IV <[email protected]> |
[Bugfix] Fix ICE on constexpr vector splat.
In {CG,}ExprConstant.cpp, we weren't treating vector splats properly. This patch makes us treat splats more properly.
Additionally, this patch adds a new
[Bugfix] Fix ICE on constexpr vector splat.
In {CG,}ExprConstant.cpp, we weren't treating vector splats properly. This patch makes us treat splats more properly.
Additionally, this patch adds a new cast kind which allows a bool->int cast to result in -1 or 0, instead of 1 or 0 (for true and false, respectively), so we can sanely model OpenCL bool->int casts in the AST.
Differential Revision: http://reviews.llvm.org/D14877
llvm-svn: 257559
show more ...
|
|
Revision tags: llvmorg-3.7.1, llvmorg-3.7.1-rc2, llvmorg-3.7.1-rc1 |
|
| #
cc2a6e06 |
| 09-Nov-2015 |
Tim Northover <[email protected]> |
Atomics: support __c11_* calls on _Atomic struct types.
When a struct's size is not a power of 2, the corresponding _Atomic() type is promoted to the nearest. We already correctly handled normal C++
Atomics: support __c11_* calls on _Atomic struct types.
When a struct's size is not a power of 2, the corresponding _Atomic() type is promoted to the nearest. We already correctly handled normal C++ expressions of this form, but direct calls to the __c11_atomic_whatever builtins ended up performing dodgy operations on the smaller non-atomic types (e.g. memcpy too much). Later optimisations removed this as undefined behaviour.
This patch converts EmitAtomicExpr to allocate its temporaries at the full atomic width, sidestepping the issue.
llvm-svn: 252507
show more ...
|
| #
2bf9b4c0 |
| 20-Oct-2015 |
Alexey Bataev <[email protected]> |
[DEBUG INFO] Emit debug info for type used in explicit cast only. Currently debug info for types used in explicit cast only is not emitted. It happened after a patch for better alignment handling. Th
[DEBUG INFO] Emit debug info for type used in explicit cast only. Currently debug info for types used in explicit cast only is not emitted. It happened after a patch for better alignment handling. This patch fixes this bug. Differential Revision: http://reviews.llvm.org/D13582
llvm-svn: 250795
show more ...
|