llvm-svn: 107684

and give a more precise return type for some of the type-creation methods.

llvm-svn: 107683

llvm-svn: 107680

llvm-svn: 107678

an IRBuilder.

llvm-svn: 107677

if profitable.

llvm-svn: 107673

llvm-svn: 107670

Patch by Kenneth Hoste.

llvm-svn: 107669

llvm-svn: 107668

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: 107667

which do not depend on SelectionDAG.

llvm-svn: 107666

should be used for.

llvm-svn: 107661

from getPhysicalRegisterRegClass.

llvm-svn: 107660

clarify a few other things.

llvm-svn: 107659

Fix a major regression on COFF targets introduced by r103267: 'discardable' section means that it is used only during the program load and can be discarded afterwards.
This way *only* debug sections can be discarded, but not the opposite. Seems like the copy-and-pasto from ELF code, since there it contains the reverse flag ('alloc').

llvm-svn: 107658

llvm-svn: 107657

llvm-svn: 107656

the pseudo instruction is not at the end of the block.

llvm-svn: 107655

llvm-svn: 107641

registers.  Split out testcases per architecture and os
now.

Patch from Nelson Elhage.

llvm-svn: 107640

llvm-svn: 107637

kind.

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

llvm-svn: 107636

llvm-svn: 107635

llvm-svn: 107625

llvm-svn: 107622

llvm-svn: 107615

llvm-svn: 107614

llvm-svn: 107613

llvm-svn: 107612

llvm-svn: 107610

v2f32 is illegal on x86.

llvm-svn: 107609

llvm-svn: 107608

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

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: 107587

llvm-svn: 107585

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

llvm-svn: 107583