[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 ...

Re-commit "[Temporary] Add an ExprWithCleanups for each C++ MaterializeTemporaryExpr."

Since D21243 fixes relative clang-tidy tests.

This reverts commit a71d9fbd41e99def9159af2b01ef6509394eaeed.

l

Re-commit "[Temporary] Add an ExprWithCleanups for each C++ MaterializeTemporaryExpr."

Since D21243 fixes relative clang-tidy tests.

This reverts commit a71d9fbd41e99def9159af2b01ef6509394eaeed.

llvm-svn: 273312

show more ...

[CodeGen] Use pointer-sized integers for ptrtoint sources

Given something like:
void *v = (void *)100;

We need to synthesize a ptrtoint operation from 100. During constant
emission, we choose i64

[CodeGen] Use pointer-sized integers for ptrtoint sources

Given something like:
void *v = (void *)100;

We need to synthesize a ptrtoint operation from 100. During constant
emission, we choose i64 as the type for our constant because it
guaranteed not to drop any bits from our CharUnits representation of the
value. However, this is suboptimal for 32-bit targets: LLVM passes like
GlobalOpt will get confused by these sorts of casts resulting in
pessimization.

Instead, make sure the ptrtoint operand has a pointer-sized integer
type.

llvm-svn: 273020

show more ...

Revert "[Temporary] Add an ExprWithCleanups for each C++ MaterializeTemporaryExpr."

This reverts r272296, since there are clang-tidy failures that appear to
be caused by this change.

llvm-svn: 2723

Revert "[Temporary] Add an ExprWithCleanups for each C++ MaterializeTemporaryExpr."

This reverts r272296, since there are clang-tidy failures that appear to
be caused by this change.

llvm-svn: 272310

show more ...

[Temporary] Add an ExprWithCleanups for each C++ MaterializeTemporaryExpr.

These ExprWithCleanups are added for holding a RunCleanupsScope not
for destructor calls; rather, they are for lifetime mar

[Temporary] Add an ExprWithCleanups for each C++ MaterializeTemporaryExpr.

These ExprWithCleanups are added for holding a RunCleanupsScope not
for destructor calls; rather, they are for lifetime marks. This requires
ExprWithCleanups to keep a bit to indicate whether it have cleanups with
side effects (e.g. dtor calls).

Differential Revision: http://reviews.llvm.org/D20498

llvm-svn: 272296

show more ...

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

Update for LLVM function name change.

llvm-svn: 257802

[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 ...

Clean ExprConstant/CGExprConstant up a bit. NFC.

llvm-svn: 255314

PR25368: Replace workaround for build failure with modules enabled with a fix
for the root cause. The 'using llvm::isa;' declaration in Basic/LLVM.h only
pulls the declarations of llvm::isa that were

PR25368: Replace workaround for build failure with modules enabled with a fix
for the root cause. The 'using llvm::isa;' declaration in Basic/LLVM.h only
pulls the declarations of llvm::isa that were declared prior to it into
namespace clang. In a modules build, this is a hermetic set of just the
declarations from LLVM. In a non-modules build, we happened to also pull the
declaration from lib/CodeGen/Address.h into namespace clang, which made the
code in question accidentally compile.

llvm-svn: 252211

show more ...

CGExprConstant.cpp: Appease Modules.

llvm-svn: 251713

[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 ...

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 ...

[CodeGen] Rename EmitMemberPointer to EmitMemberFunctionPointer

llvm-svn: 240382

Revert r240270 ("Fixed/added namespace ending comments using clang-tidy").

llvm-svn: 240353

Fixed/added namespace ending comments using clang-tidy. NFC

The patch is generated using this command:

$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comme

Fixed/added namespace ending comments using clang-tidy. NFC

The patch is generated using this command:

$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang

To reduce churn, not touching namespaces spanning less than 10 lines.

llvm-svn: 240270

show more ...

Implementing C99 partial re-initialization behavior (DR-253)

Based on previous discussion on the mailing list, clang currently lacks support
for C99 partial re-initialization behavior:
Reference: ht

Implementing C99 partial re-initialization behavior (DR-253)

Based on previous discussion on the mailing list, clang currently lacks support
for C99 partial re-initialization behavior:
Reference: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-April/029188.html
Reference: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_253.htm

This patch attempts to fix this problem.

Given the following code snippet,

struct P1 { char x[6]; };
struct LP1 { struct P1 p1; };

struct LP1 l = { .p1 = { "foo" }, .p1.x[2] = 'x' };
// this example is adapted from the example for "struct fred x[]" in DR-253;
// currently clang produces in l: { "\0\0x" },
// whereas gcc 4.8 produces { "fox" };
// with this fix, clang will also produce: { "fox" };


Differential Review: http://reviews.llvm.org/D5789

llvm-svn: 239446

show more ...

[CodeGen] Indirect fields can initialize a union

The first named data member is the field used to default initialize the
union. An IndirectFieldDecl can introduce the first named data member
of a u

[CodeGen] Indirect fields can initialize a union

The first named data member is the field used to default initialize the
union. An IndirectFieldDecl can introduce the first named data member
of a union.

llvm-svn: 238649

show more ...

[CodeGen] Handle flexible array members containing pointers to members

Types can be classified as being zero-initializable or
non-zero-initializable. We used to classify array types by giving them

[CodeGen] Handle flexible array members containing pointers to members

Types can be classified as being zero-initializable or
non-zero-initializable. We used to classify array types by giving them
the classification of their base element type. However, incomplete
array types are never initialized directly and thus are always
zero-initializable.

llvm-svn: 238256

show more ...

Replace getPointeeType()->isFunctionType with isMemberDataPointerType

llvm-svn: 235682

[opaque pointer type] Update for GEP API changes in LLVM

Now the GEP constant utility functions require the type to be explicitly
passed (since eventually the pointer type will be opaque and not con

[opaque pointer type] Update for GEP API changes in LLVM

Now the GEP constant utility functions require the type to be explicitly
passed (since eventually the pointer type will be opaque and not convey
the required type information). For now callers can still pass nullptr
(though none were needed here in Clang, which is nice) if
convenienc/necessary, but eventually that will be disallowed as well.

llvm-svn: 233937

show more ...

CodeGen: Correctly initialize bitfields with non-constant initializers

It is possible to construct an initializer for a bitfield which is not
constant. Instead of emitting code to initialize the fi

CodeGen: Correctly initialize bitfields with non-constant initializers

It is possible to construct an initializer for a bitfield which is not
constant. Instead of emitting code to initialize the field before the
execution of main, clang would crash.

llvm-svn: 232285

show more ...

CodeGen: Optimize emssion of zeroinitialzied arrays

Create an ConstantAggregateZero upfront if we see that it is viable.
This saves us from having to manually push_back each and every
initializer an

CodeGen: Optimize emssion of zeroinitialzied arrays

Create an ConstantAggregateZero upfront if we see that it is viable.
This saves us from having to manually push_back each and every
initializer and then looping back over them to determine if they are
'null'.

llvm-svn: 224908

show more ...

CodeGen: Compound literals with funny types shouldn't crash

CodeGen assumed that a compound literal with array type should have a
corresponding LLVM IR array type.

We had two bugs in this area:
- Z

CodeGen: Compound literals with funny types shouldn't crash

CodeGen assumed that a compound literal with array type should have a
corresponding LLVM IR array type.

We had two bugs in this area:
- Zero sized arrays in compound literals would lead to the creation of
an opaque type. This is unnecessary, we should just create an array
type with a bound of zero.
- Funny record types (like unions) lead to exotic IR types for compound
literals. In this case, CodeGen must be prepared to deal with the
possibility that it might not have an array IR type.

This fixes PR21912.

llvm-svn: 224219

show more ...

Use nullptr to silence -Wsentinel when self-hosting on Windows

Richard rejected my Sema change to interpret an integer literal zero in
a varargs context as a null pointer, so -Wsentinel sees an inte

Use nullptr to silence -Wsentinel when self-hosting on Windows

Richard rejected my Sema change to interpret an integer literal zero in
a varargs context as a null pointer, so -Wsentinel sees an integer
literal zero and fires off a warning. Only CodeGen currently knows that
it promotes integer literal zeroes in this context to pointer size on
Windows. I didn't want to teach -Wsentinel about that compatibility
hack. Therefore, I'm migrating to C++11 nullptr.

llvm-svn: 223079

show more ...