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

llvm-svn: 107593

contain all the same information that their Types do, we will fall back to
traversing the Types instead. The default TypeLoc visitor calls the matching
Type visitor so that existing clients should continue to work with no change.

Also adds element traversal to the ExtVectorType.

llvm-svn: 107592

Infer alignments of fixed frame objects when they are constructed. This ensures remat'ed loads from fixed slots have the right alignments.

llvm-svn: 107591

llvm-svn: 107589

llvm-svn: 107588

llvm-svn: 107587

Initial implementation of double-precision soft-float division, moved a couple utility functions from the multiplications into the utility header

llvm-svn: 107586

llvm-svn: 107585

(SDNPMemOperand). This way when they're morphed the memory operands will be
copied as well.

llvm-svn: 107583

llvm-svn: 107582

llvm-svn: 107581

second round of low-level interface squeeze-out:
making all of CallInst's low-level operand accessors
private

If you get compile errors I strongly urge you to
update your code.


I tried to write the necessary clues into the
header where the compiler may point to, but no
guarantees. It works for my GCC.

You have several options to update your code:

- you can use the v2.8 ArgOperand accessors
- you can go via a temporary CallSite
- you can upcast to, say, User and call its
  low-level accessors if your code is definitely
  operand-order agnostic.

If you run into serious problems, please
comment in below thread (and back out this
revision only if absolutely necessary):

<http://groups.google.com/group/llvm-dev/browse_thread/thread/64650cf343b28271>

llvm-svn: 107580

llvm-svn: 107579

Type hierarchy. Without this, TypeLocNodes.def will give you wrong type
hierarchy information (claiming that ObjCObjectTypeLoc is the base of
ObjCInterfaceTypeLoc, which it wasn't).

llvm-svn: 107578