kind.

Also fold some functions that fit on a line to a single line.

llvm-svn: 107636

llvm-svn: 107635

llvm-svn: 107634

Improve NULL-checking for CFRetain/CFRelease. We now remember that the argument was non-NULL, and we report where the null assumption came from (like AttrNonNullChecker already did).

llvm-svn: 107633

llvm-svn: 107632

self-host.  Hopefully these results hold up on different platforms.  

I tried to keep the GNU ObjC runtime happy, but it's hard for me to test.
Reimplement how clang generates IR for exceptions.  Instead of creating new
invoke destinations which sequentially chain to the previous destination,
push a more semantic representation of *why* we need the cleanup/catch/filter
behavior, then collect that information into a single landing pad upon request.

Also reorganizes how normal cleanups (i.e. cleanups triggered by non-exceptional
control flow) are generated, since it's actually fairly closely tied in with
the former.  Remove the need to track which cleanup scope a block is associated
with.

Document a lot of previously poorly-understood (by me, at least) behavior.

The new framework implements the Horrible Hack (tm), which requires every
landing pad to have a catch-all so that inlining will work.  Clang no longer
requires the Horrible Hack just to make exceptions flow correctly within
a function, however.  The HH is an unfortunate requirement of LLVM's EH IR.

llvm-svn: 107631

llvm-svn: 107630

coerce cases (e.g. {double,int}) which avoids fastisel
bailing out at -O0.

llvm-svn: 107628

alloca for an argument.  Make sure the argument gets the proper
decl alignment, which may be different than the type alignment.

This fixes PR7567

llvm-svn: 107627

llvm-svn: 107626

llvm-svn: 107625

llvm-svn: 107624

Patch by Stephen Wilson!

llvm-svn: 107623

llvm-svn: 107622

wasn't handling array padding elements right.

llvm-svn: 107621

Everyone knows that no bugs are ever possible with bitfields.

llvm-svn: 107620

We can now use a PCH'ed <map>.

llvm-svn: 107617

llvm-svn: 107616

llvm-svn: 107615

llvm-svn: 107614

llvm-svn: 107613

llvm-svn: 107612

Support sizeof for VLA expressions (sizeof(someVLA)). sizeof(int[n]) still unimplemented. A VLA region's sizeof value matches its extent.

llvm-svn: 107611

llvm-svn: 107610

v2f32 is illegal on x86.

llvm-svn: 107609

llvm-svn: 107608

llvm-svn: 107607

class is available in the same translation unit when it's needed. So we make 
all of them invalid Entity.

llvm-svn: 107606

llvm-svn: 107605

llvm-svn: 107604

llvm-svn: 107603

llvm-svn: 107602

the example in the testcase, we now generate:

_test1:                                 ## @test1
	movss	4(%esp), %xmm0
	addss	8(%esp), %xmm0
	movl	12(%esp), %eax
	movss	%xmm0, (%eax)
	ret

instead of:

_test1:                                                     ## @test1
	subl	$20, %esp
	movl	24(%esp), %eax
	movq	%mm0, (%esp)
	movq	%mm0, 8(%esp)
	movss	(%esp), %xmm0
	addss	12(%esp), %xmm0
	movss	%xmm0, (%eax)
	addl	$20, %esp
	ret

v2f32 support did not work reliably because most of the X86
backend didn't know it was legal.  It was apparently only added
to support returning source-level v2f32 values in MMX registers
in x86-32 mode.  If ABI compatibility is important on this
GCC-extended-vector type for some reason, then the frontend
should generate IR that returns v2i32 instead of v2f32.  However,
we generally don't try very hard to be abi compatible on gcc
extended vectors. 

llvm-svn: 107601

v2f32 as legal in 32-bit mode.  It is just as terrible there,
but I just care about x86-64 and noone claims it is valuable
in 64-bit mode.

llvm-svn: 107600

llvm-svn: 107599

Some of the invariant checks for creating Record/Enum types don't hold true during PCH reading.
Introduce more suitable ASTContext::getRecordType() and getEnumType().

llvm-svn: 107598

Read/write more information of ASTContext for PCH. Overriden methods and instantiated-from information.

llvm-svn: 107597

Before this commit, visible decls added before deserialization were ignored.
This was not an issue since name lookup (that usually comes before the addition) forces deserialization
but it is an issue for lazily declared class implicit members.

We can use a PCH'ed <string> now.

llvm-svn: 107596

Currently, adding it to visible decls of a PCH'ed translation unit has no effect because
adding visible decls before deserialization has no effect (the decls won't be visible).
This will be fixed in a future commit; then it will force deserialization of visible decls, so avoid pointlessly installing it.

llvm-svn: 107595

llvm-svn: 107594