[OpenCL][NFC] Unify ZeroToOCL* cast types

Reviewers: Anastasia, yaxunl

Reviewed By: Anastasia

Subscribers: asavonic, cfe-commits

Differential Revision: https://reviews.llvm.org/D52654

llvm-svn:

[OpenCL][NFC] Unify ZeroToOCL* cast types

Reviewers: Anastasia, yaxunl

Reviewed By: Anastasia

Subscribers: asavonic, cfe-commits

Differential Revision: https://reviews.llvm.org/D52654

llvm-svn: 345038

show more ...

[Fixed Point Arithmetic] FixedPointCast

This patch is a part of https://reviews.llvm.org/D48456 in an attempt to
split them up. This contains the code for casting between fixed point types
and other

[Fixed Point Arithmetic] FixedPointCast

This patch is a part of https://reviews.llvm.org/D48456 in an attempt to
split them up. This contains the code for casting between fixed point types
and other fixed point types.

The method for converting between fixed point types is based off the convert()
method in APFixedPoint.

Differential Revision: https://reviews.llvm.org/D50616

llvm-svn: 344530

show more ...

Remove \brief commands from doxygen comments.

This is similar to the LLVM change https://reviews.llvm.org/D46290.

We've been running doxygen with the autobrief option for a couple of
years now. Thi

Remove \brief commands from doxygen comments.

This is similar to the LLVM change https://reviews.llvm.org/D46290.

We've been running doxygen with the autobrief option for a couple of
years now. This makes the \brief markers into our comments
redundant. Since they are a visual distraction and we don't want to
encourage more \brief markers in new code either, this patch removes
them all.

Patch produced by

for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done
for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done

Differential Revision: https://reviews.llvm.org/D46320

llvm-svn: 331834

show more ...

Fix typos in clang

Found via codespell -q 3 -I ../clang-whitelist.txt
Where whitelist consists of:

archtype
cas
classs
checkk
compres
definit
frome
iff
inteval
ith
lod
metho

Fix typos in clang

Found via codespell -q 3 -I ../clang-whitelist.txt
Where whitelist consists of:

archtype
cas
classs
checkk
compres
definit
frome
iff
inteval
ith
lod
methode
nd
optin
ot
pres
statics
te
thru

Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few
files that have dubious fixes reverted.)

Differential revision: https://reviews.llvm.org/D44188

llvm-svn: 329399

show more ...

Delete BuiltinCC. NFC.

It is always identical to RuntimeCC.

llvm-svn: 328050

[CodeGen] Ignore OpaqueValueExprs that are unique references to their
source expressions when iterating over a PseudoObjectExpr's semantic
subexpression list.

Previously the loop in emitPseudoObject

[CodeGen] Ignore OpaqueValueExprs that are unique references to their
source expressions when iterating over a PseudoObjectExpr's semantic
subexpression list.

Previously the loop in emitPseudoObjectExpr would emit the IR for each
OpaqueValueExpr that was in a PseudoObjectExpr's semantic-form
expression list and use the result when the OpaqueValueExpr later
appeared in other expressions. This caused an assertion failure when
AggExprEmitter tried to copy the result of an OpaqueValueExpr and the
copied type didn't have trivial copy/move constructors or assignment
operators.

This patch adds flag IsUnique to OpaqueValueExpr which indicates it is a
unique reference to its source expression (it is not used in multiple
places). The loop in emitPseudoObjectExpr ignores OpaqueValueExprs that
are unique and CodeGen visitors simply traverse the source expressions
of such OpaqueValueExprs.

rdar://problem/34363596

Differential Revision: https://reviews.llvm.org/D39562

llvm-svn: 327939

show more ...

[Complex] Don't use __div?c3 when building with fast-math.

Summary: Plant an inline version of "((ac+bd)/(cc+dd)) + i((bc-ad)/(cc+dd))" instead.

Patch by Paul Walker.

Reviewed By: hfinkel

Differe

[Complex] Don't use __div?c3 when building with fast-math.

Summary: Plant an inline version of "((ac+bd)/(cc+dd)) + i((bc-ad)/(cc+dd))" instead.

Patch by Paul Walker.

Reviewed By: hfinkel

Differential Revision: https://reviews.llvm.org/D40299

llvm-svn: 321183

show more ...

Remove unused variables. No functionality change.

llvm-svn: 315185

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

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

Don't assume cleanup emission preserves dominance in expr evaluation

Summary:
Because of the existence branches out of GNU statement expressions, it
is possible that emitting cleanups for a full exp

Don't assume cleanup emission preserves dominance in expr evaluation

Summary:
Because of the existence branches out of GNU statement expressions, it
is possible that emitting cleanups for a full expression may cause the
new insertion point to not be dominated by the result of the inner
expression. Consider this example:

struct Foo { Foo(); ~Foo(); int x; };
int g(Foo, int);
int f(bool cond) {
int n = g(Foo(), ({ if (cond) return 0; 42; }));
return n;
}

Before this change, result of the call to 'g' did not dominate its use
in the store to 'n'. The early return exit from the statement expression
branches to a shared cleanup block, which ends in a switch between the
fallthrough destination (the assignment to 'n') or the function exit
block.

This change solves the problem by spilling and reloading expression
evaluation results when any of the active cleanups have branches.

I audited the other call sites of enterFullExpression, and they don't
appear to keep and Values live across the site of the cleanup, except in
ARC code. I wasn't able to create a test case for ARC that exhibits this
problem, though.

Reviewers: rjmccall, rsmith

Subscribers: cfe-commits

Differential Revision: https://reviews.llvm.org/D30590

llvm-svn: 297084

show more ...

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

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

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

Refactor call emission to package the function pointer together with
abstract information about the callee. NFC.

The goal here is to make it easier to recognize indirect calls and
trigger additiona

Refactor call emission to package the function pointer together with
abstract information about the callee. NFC.

The goal here is to make it easier to recognize indirect calls and
trigger additional logic in certain cases. That logic will come in
a later patch; in the meantime, I felt that this was a significant
improvement to the code.

llvm-svn: 285258

show more ...

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

[NFC] Header cleanup

Summary: Removed unused headers, replaced some headers with forward class declarations

Patch by: Eugene <[email protected]>

Differential Revision: https://reviews.llvm.org/D20

[NFC] Header cleanup

Summary: Removed unused headers, replaced some headers with forward class declarations

Patch by: Eugene <[email protected]>

Differential Revision: https://reviews.llvm.org/D20100

llvm-svn: 275882

show more ...

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

Preserve exceptions information during calls code generation.

This patch changes the generation of CGFunctionInfo to contain
the FunctionProtoType if it is available. This enables the code
generat

Preserve exceptions information during calls code generation.

This patch changes the generation of CGFunctionInfo to contain
the FunctionProtoType if it is available. This enables the code
generation for call instructions to look into this type for
exception information and therefore generate better quality
IR - it will not create invoke instructions for functions that
are know not to throw.

llvm-svn: 253926

show more ...

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

Support __builtin_ms_va_list.

Summary:
This change adds support for `__builtin_ms_va_list`, a GCC extension for
variadic `ms_abi` functions. The existing `__builtin_va_list` support is
inadequate fo

Support __builtin_ms_va_list.

Summary:
This change adds support for `__builtin_ms_va_list`, a GCC extension for
variadic `ms_abi` functions. The existing `__builtin_va_list` support is
inadequate for this because `va_list` is defined differently in the Win64
ABI vs. the System V/AMD64 ABI.

Depends on D1622.

Reviewers: rsmith, rnk, rjmccall

CC: cfe-commits

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

llvm-svn: 247941

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

Propagate SourceLocations through to get a Loc on float_cast_overflow

Summary:
float_cast_overflow is the only UBSan check without a source location attached.
This patch propagates SourceLocations w

Propagate SourceLocations through to get a Loc on float_cast_overflow

Summary:
float_cast_overflow is the only UBSan check without a source location attached.
This patch propagates SourceLocations where necessary to get them to the
EmitCheck() call.

Reviewers: rsmith, ABataev, rjmccall

Subscribers: cfe-commits

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

llvm-svn: 244568

show more ...

Don't repeat function names in comments. NFC.

llvm-svn: 244018

InstrProf: Stop using RegionCounter outside of CodeGenPGO (NFC)

The RegionCounter type does a lot of legwork, but most of it is only
meaningful within the implementation of CodeGenPGO. The uses else

InstrProf: Stop using RegionCounter outside of CodeGenPGO (NFC)

The RegionCounter type does a lot of legwork, but most of it is only
meaningful within the implementation of CodeGenPGO. The uses elsewhere
in CodeGen generally just want to increment or read counters, so do
that directly.

llvm-svn: 235664

show more ...