History log of /llvm-project-15.0.7/clang/lib/CodeGen/CGExprAgg.cpp (Results 76 – 100 of 476)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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 ...


12345678910>>...20