Handle va_arg on struct types for the le32 target (PNaCl and Emscripten)

PNaCl and Emscripten can both handle va_arg IR instructions with
struct type.

Also add a test to cover generating a va_arg I

Handle va_arg on struct types for the le32 target (PNaCl and Emscripten)

PNaCl and Emscripten can both handle va_arg IR instructions with
struct type.

Also add a test to cover generating a va_arg IR instruction from
va_arg in C on le32 (as already handled by VisitVAArgExpr() in
CGExprScalar.cpp), which was not covered by a test before.

(This fixes https://code.google.com/p/nativeclient/issues/detail?id=2381)

Differential Revision: http://llvm-reviews.chandlerc.com/D2539

llvm-svn: 199830

show more ...

CodeGen: Rename adjustFallThroughCount -> adjustForControlFlow

adjustFallThroughCount isn't a good name, and the documentation was
even worse. This commit attempts to clarify what it's for and when

CodeGen: Rename adjustFallThroughCount -> adjustForControlFlow

adjustFallThroughCount isn't a good name, and the documentation was
even worse. This commit attempts to clarify what it's for and when to
use it.

llvm-svn: 199139

show more ...

CodeGen: Initial instrumentation based PGO implementation

llvm-svn: 198640

Add front-end infrastructure now address space casts are in LLVM IR.

With the introduction of explicit address space casts into LLVM, there's
a need to provide a new cast kind the front-end can crea

Add front-end infrastructure now address space casts are in LLVM IR.

With the introduction of explicit address space casts into LLVM, there's
a need to provide a new cast kind the front-end can create for C/OpenCL/CUDA
and code to produce address space casts from those kinds when appropriate.

Patch by Michele Scandale!

llvm-svn: 197036

show more ...

Thread a SourceLocation into the EmitCheck for "load_invalid_value". This occurs
when scalars are loaded / undergo lvalue-to-rvalue conversion.

llvm-svn: 191808

Make IgnoreParens() look through ChooseExprs.

This is the same way GenericSelectionExpr works, and it's generally a
more consistent approach.

A large part of this patch is devoted to caching the va

Make IgnoreParens() look through ChooseExprs.

This is the same way GenericSelectionExpr works, and it's generally a
more consistent approach.

A large part of this patch is devoted to caching the value of the condition
of a ChooseExpr; it's needed to avoid threading an ASTContext into
IgnoreParens().

Fixes <rdar://problem/14438917>.

llvm-svn: 186738

show more ...

Fix build.

Sorry about that.

llvm-svn: 186054

Simplify atomic load/store IRGen.

Also fixes a couple minor bugs along the way; see testcases.

llvm-svn: 186049

Simplify: we don't need any special-case lifetime extension when initializing
declarations of reference type; they're handled by the general case handling of
MaterializeTemporaryExpr.

llvm-svn: 1838

Simplify: we don't need any special-case lifetime extension when initializing
declarations of reference type; they're handled by the general case handling of
MaterializeTemporaryExpr.

llvm-svn: 183875

show more ...

PR12086, PR15117

Introduce CXXStdInitializerListExpr node, representing the implicit
construction of a std::initializer_list<T> object from its underlying array.
The AST representation of such an ex

PR12086, PR15117

Introduce CXXStdInitializerListExpr node, representing the implicit
construction of a std::initializer_list<T> object from its underlying array.
The AST representation of such an expression goes from an InitListExpr with a
flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr
containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr).

This more detailed representation has several advantages, the most important of
which is that the new MaterializeTemporaryExpr allows us to directly model
lifetime extension of the underlying temporary array. Using that, this patch
*drastically* simplifies the IR generation of this construct, provides IR
generation support for nested global initializer_list objects, fixes several
bugs where the destructors for the underlying array would accidentally not get
invoked, and provides constant expression evaluation support for
std::initializer_list objects.

llvm-svn: 183872

show more ...

Fix assert on temporary std::initializer_list.

llvm-svn: 182615

C++1y: Allow aggregates to have default initializers.

Add a CXXDefaultInitExpr, analogous to CXXDefaultArgExpr, and use it both in
CXXCtorInitializers and in InitListExprs to represent a default ini

C++1y: Allow aggregates to have default initializers.

Add a CXXDefaultInitExpr, analogous to CXXDefaultArgExpr, and use it both in
CXXCtorInitializers and in InitListExprs to represent a default initializer.

There's an additional complication here: because the default initializer can
refer to the initialized object via its 'this' pointer, we need to make sure
that 'this' points to the right thing within the evaluation.

llvm-svn: 179958

show more ...

Standardize accesses to the TargetInfo in IR-gen.

Patch by Stephen Lin!

llvm-svn: 179638

Promote atomic type sizes up to a power of two, capped by
MaxAtomicPromoteWidth. Fix a ton of terrible bugs with
_Atomic types and (non-intrinsic-mediated) loads and stores
thereto.

llvm-svn: 176658

Change hasAggregateLLVMType, which conflates complex and
aggregate types in a profoundly wrong way that has to be
worked around in every call site, to getEvaluationKind,
which classifies and distingu

Change hasAggregateLLVMType, which conflates complex and
aggregate types in a profoundly wrong way that has to be
worked around in every call site, to getEvaluationKind,
which classifies and distinguishes between all of these
cases.

Also, normalize the API for loading and storing complexes.

I'm working on a larger patch and wanted to pull these
changes out, but it would have be annoying to detangle
them from each other.

llvm-svn: 176656

show more ...

Evaluate compound literals directly into the result aggregate
when that aggregate isn't potentially aliased.

llvm-svn: 176654

patch for PR9027 and // rdar://11861085
Title: [PR9027] volatile struct bug: member is not loaded at -O;
This is caused by last flag passed to @llvm.memcpy being false,
not honoring that aggregate h

patch for PR9027 and // rdar://11861085
Title: [PR9027] volatile struct bug: member is not loaded at -O;
This is caused by last flag passed to @llvm.memcpy being false,
not honoring that aggregate has at least one 'volatile' data member
(even though aggregate itself has not been qualified as 'volatile'.
As a result, optimization optimizes away the memcpy altogether.
Patch review by John MaCall (I still need to fix up a test though).

llvm-svn: 173535

show more ...

Implement OpenCL event_t as Clang builtin type, including event_t related OpenCL restrictions (OpenCL 1.2 spec 6.9)

llvm-svn: 172973

Rewrite #includes for llvm/Foo.h to llvm/IR/Foo.h as appropriate to
reflect the migration in r171366.

Re-sort the #include lines to reflect the new paths.

llvm-svn: 171369

Reinstate r170806, reverted in r170835, with a fix use i1 instead of i8 for a value-initialized bool!

llvm-svn: 170837

Revert r170806, "Fix some bugs where we would sometimes use 0, not -1, when emitting a null constant of type pointer-to-data-member."

It broke stage2.

llvm-svn: 170835

Fix some bugs where we would sometimes use 0, not -1, when emitting a null constant of type pointer-to-data-member.

llvm-svn: 170806

Sort all of Clang's files under 'lib', and fix up the broken headers
uncovered.

This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/util

Sort all of Clang's files under 'lib', and fix up the broken headers
uncovered.

This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.

I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.

llvm-svn: 169237

show more ...

A step towards sorting out handling of triviality of special members in C++11.

Separate out the notions of 'has a trivial special member' and 'has a
non-trivial special member', and use them appropr

A step towards sorting out handling of triviality of special members in C++11.

Separate out the notions of 'has a trivial special member' and 'has a
non-trivial special member', and use them appropriately. These are not
opposites of one another (there might be no special member, or in C++11 there
might be a trivial one and a non-trivial one). The CXXRecordDecl predicates
continue to produce incorrect results, but do so in fewer cases now, and
they document the cases where they might be wrong.

No functionality changes are intended here (they will come when the predicates
start producing the right answers...).

llvm-svn: 168119

show more ...

Simplify: replace getContext().getLangOpts() with just getLangOpts().

llvm-svn: 167261