The simplify-libcalls pass has been removed from LLVM.  Thus
'PMBuilder.DisableSimplifyLibCalls' does not exist anymore.
The disabling/enabling of library call simplifications is
done through the TargetLibraryInfo which is already wired
up in Clang.

llvm-svn: 184458

Revert r184205 and associated patches while investigating issue with broken buildbot (possible interaction with LTO)

<rdar://problem/14209661>

llvm-svn: 184384

Debug Info: PR14763/r183329 - specify that non-trivial pass-by-value parameters are stored indirectly

This is to fix the location information for such parameters to refer to
the object accessible through the pointer rather than to the pointer
parameter itself.

llvm-svn: 184367

Corrections to r184205 ('this'-return optimization) due to the wrong version of the patch being committed originally.
1) Removed useless return value of CGCXXABI::EmitConstructorCall and CGCXXABI::EmitVirtualDestructorCall and implementations
2) Corrected last portion of CodeGenCXX/constructor-destructor-return-this to correctly test for non-'this'-return of virtual destructor calls

llvm-svn: 184330

CGCleanup.h isn't meant to be included by all of CodeGen according to
John.

llvm-svn: 184321

In Itanium, dynamic classes have one vtable with several different
address points for dynamic base classes that can't share vtables.

In the MS C++ ABI, each vbtable that can't be shared gets its own
symbol, similar to how ctor vtables work in Itanium.  However, instead
of mangling the subobject offset into the symbol, the unique portions of
the inheritance path are mangled into the symbol to make it unique.

This patch implements the MSVC 2012 scheme for forming unique vbtable
symbol names.  MSVC 2010 use the same mangling with a different subset
of the path.  Implementing that mangling and possibly others is TODO.

Each vbtable is an array of i32 offsets from the vbptr that points to it
to another virtual base subobject.  The first entry of a vbtable always
points to the base of the current subobject, implying that it is the
same no matter which parent class contains it.

Reviewers: rjmccall

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

llvm-svn: 184309

llvm-svn: 184284

These options will add a module flag with name "Dwarf Version".
The behavior flag is currently set to Warning, so when two values disagree,
a warning will be emitted.

llvm-svn: 184276

rdar://problem/14101097

llvm-svn: 184259

limiting debug info.

FIXME: There is still work left to do here, the testcase should work even with -flimit-debug-info.

rdar://problem/14101097

llvm-svn: 184252

[multiprecision-builtins] Added missing builtin __builtin_{add,sub}cb for {add,sub} with carry for bytes.

I have had several people ask me about why this builtin was not available in
clang (since it seems like a logical conclusion). This patch implements said
builtins.

Relevant tests are included as well. I also updated the Clang language extension reference.

rdar://14192664.

llvm-svn: 184227

CodeGen: Have 'this'-returning constructors and destructors to take advantage of the new backend 'returned' attribute.

The backend will now use the generic 'returned' attribute to form tail calls where possible, as well as avoid save-restores of 'this' in some cases (specifically the cases that matter for the ARM C++ ABI).

This patch also reverts a prior front-end only partial implementation of these optimizations, since it's no longer required.

llvm-svn: 184205

llvm-svn: 184166

between a block assignment and the entry of the block function. In reality
this wouldn't work anyway because blocks are predominantly created
on-the-fly inside of an ObjC method invocation.
The proper fix for the ambiguity is to use -gcolumn-info to differentiate
the breakpoints.

This is expected to break some block-related darwin-gdb tests.

rdar://problem/14039866

llvm-svn: 184157

llvm-svn: 184137

With this patch we assign VisibleNoLinkage to static locals in inline functions.
This lets us simplify CodeGen a bit.

llvm-svn: 184114

possible.

llvm-svn: 183967

process of trying to fix the related issue for block literals.)

llvm-svn: 183951

declarations of reference type; they're handled by the general case handling of
MaterializeTemporaryExpr.

llvm-svn: 183875

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

were lacking ExprWithCleanups nodes in some cases where the new approach to
lifetime extension needed them).

Original commit message:

Rework IR emission for lifetime-extended temporaries. Instead of trying to walk
into the expression and dig out a single lifetime-extended entity and manually
pull its cleanup outside the expression, instead keep a list of the cleanups
which we'll need to emit when we get to the end of the full-expression. Also
emit those cleanups early, as EH-only cleanups, to cover the case that the
full-expression does not terminate normally. This allows IR generation to
properly model temporary lifetime when multiple temporaries are extended by the
same declaration.

We have a pre-existing bug where an exception thrown from a temporary's
destructor does not clean up lifetime-extended temporaries created in the same
expression and extended to automatic storage duration; that is not fixed by
this patch.

llvm-svn: 183859

llvm-svn: 183837

Fixes <rdar://problem/11224126> and PR12790.

llvm-svn: 183821

AVX vectors when AVX is turned on.

Fixes <rdar://problem/10513611>.

llvm-svn: 183813

Testcase to follow.

llvm-svn: 183776

llvm-svn: 183742

into the expression and dig out a single lifetime-extended entity and manually
pull its cleanup outside the expression, instead keep a list of the cleanups
which we'll need to emit when we get to the end of the full-expression. Also
emit those cleanups early, as EH-only cleanups, to cover the case that the
full-expression does not terminate normally. This allows IR generation to
properly model temporary lifetime when multiple temporaries are extended by the
same declaration.

We have a pre-existing bug where an exception thrown from a temporary's
destructor does not clean up lifetime-extended temporaries created in the same
expression and extended to automatic storage duration; that is not fixed by
this patch.

llvm-svn: 183721

llvm-svn: 183720

while fixing a related bug.  The fix here was simpler than I thought it
would be.

Fixes <rdar://problem/10530444>.

llvm-svn: 183718

Fixes <rdar://problem/14074868>.

llvm-svn: 183699

Also move CGCleanup.h to the top of CGCleanup.cpp to verify that
CGCleanup.h really includes what it needs.

llvm-svn: 183632

No functionality change.  CGCleanup.cpp provides the implementation for
EHScopeStack, so it seems more consistent to place the class definition
in CGCleanup.h.

This should also help solve a header ordering problem that I have.

llvm-svn: 183631

llvm-svn: 183598

Two variables with the same name declared in two if conditions in the same
scope are no longer coalesced into one.

rdar://problem/14024005

llvm-svn: 183597

llvm-svn: 183590

llvm-svn: 183586

llvm-svn: 183583

- factor the name construction part out from constructSetterName
- rename constructSetterName to the more appropriate constructSetterSelector

no functionality change intended.
rdar://problem/14035789

llvm-svn: 183582

llvm-svn: 183475

the default names, not just when the isImplicit flag is set.

rdar://problem/14035789

llvm-svn: 183474