- There is a minor semantic change here (evidenced by the test change) for
   Darwin triples that have no version component. I debated changing the default
   behavior of isOSVersionLT, but decided it made more sense for triples to be
   explicit.

llvm-svn: 129802

llvm-svn: 129801

llvm-svn: 129800

llvm-svn: 129799

llvm-svn: 129798

llvm-svn: 129796

llvm-svn: 129781

Making use of VFP / NEON floating point multiply-accumulate / subtraction is
difficult on current ARM implementations for a few reasons.
1. Even though a single vmla has latency that is one cycle shorter than a pair
   of vmul + vadd, a RAW hazard during the first (4? on Cortex-a8) can cause
   additional pipeline stall. So it's frequently better to single codegen
   vmul + vadd.
2. A vmla folowed by a vmul, vmadd, or vsub causes the second fp instruction to
   stall for 4 cycles. We need to schedule them apart.
3. A vmla followed vmla is a special case. Obvious issuing back to back RAW
   vmla + vmla is very bad. But this isn't ideal either:
     vmul
     vadd
     vmla
   Instead, we want to expand the second vmla:
     vmla
     vmul
     vadd
   Even with the 4 cycle vmul stall, the second sequence is still 2 cycles
   faster.

Up to now, isel simply avoid codegen'ing fp vmla / vmls. This works well enough
but it isn't the optimial solution. This patch attempts to make it possible to
use vmla / vmls in cases where it is profitable.

A. Add missing isel predicates which cause vmla to be codegen'ed.
B. Make sure the fmul in (fadd (fmul)) has a single use. We don't want to
   compute a fmul and a fmla.
C. Add additional isel checks for vmla, avoid cases where vmla is feeding into
   fp instructions (except for the #3 exceptional case).
D. Add ARM hazard recognizer to model the vmla / vmls hazards.
E. Add a special pre-regalloc case to expand vmla / vmls when it's likely the
   vmla / vmls will trigger one of the special hazards.

Enable these fp vmlx codegen changes for Cortex-A9.

llvm-svn: 129775

llvm-svn: 129774

(and add false dependency) when it isn't dependent on last CPSR defining
instruction. rdar://8928208

llvm-svn: 129773

Add a avoidWriteAfterWrite() target hook to identify register classes that
suffer from write-after-write hazards. For those register classes, try to avoid
writing the same register in two consecutive instructions.

This is currently disabled by default.  We should not spill to avoid hazards!
The command line flag -avoid-waw-hazard can be used to enable waw avoidance.

llvm-svn: 129772

pipelines, at least on Cortex-A9.

llvm-svn: 129771

llvm-svn: 129770

llvm-svn: 129765

This means that the new register allocator can be used with 'clang -mllvm -regalloc=greedy'.

llvm-svn: 129764

unnecessary work where possible.

llvm-svn: 129763

llvm-svn: 129761

llvm-svn: 129759

Ideally, we would match an S-register to its containing D-register, but that
requires arithmetic (divide by 2).

llvm-svn: 129756

en-mass for C++ PODs.  On my c++ test file, this cuts the fast isel rejects by 10x 
and shrinks the generated .s file by 5%

llvm-svn: 129755

llvm-svn: 129753

when they are a truncate from something else.  This eliminates fully half of all the 
fastisel rejections on a test c++ file I'm working with, which should make a substantial
improvement for -O0 compile of c++ code.

This fixed rdar://9297003 - fast isel bails out on all functions taking bools

llvm-svn: 129752

Before we would bail out on i1 arguments all together, now we just bail on
non-constant ones.  Also, we used to emit extraneous code.  e.g. test12 was:

	movb	$0, %al
	movzbl	%al, %edi
	callq	_test12

and test13 was:
	movb	$0, %al
	xorl	%edi, %edi
	movb	%al, 7(%rsp)
	callq	_test13f

Now we get:

	movl	$0, %edi
	callq	_test12
and:
	movl	$0, %edi
	callq	_test13f

llvm-svn: 129751

	testb	$1, %al
	je	LBB0_2
## BB#1:                                ## %if.then
	movb	$0, %al

instead of:

	testb	$1, %al
	jne	LBB0_1
	jmp	LBB0_2
LBB0_1:                                 ## %if.then
	movb	$0, %al

how 'bout that.

llvm-svn: 129749

a common cause of fast isel rejects on c++ code.

llvm-svn: 129748

is, it assumes addresses are 64-bit aligned (which should be the more common
case). If the alignment is found not to be aligned, then getOperandLatency()
would adjust the operand latency computation by one to compensate for it.
rdar://9294833

llvm-svn: 129742

llvm-svn: 129739

llvm-svn: 129738

This was causing a flooding of warnings with MSVC 2008. This warning was removed in MSVC 2010.

llvm-svn: 129737

H1 ... doc_title
H2 ... doc_section
H3 ... doc_subsection
H4 ... doc_subsubsection

llvm-svn: 129736

llvm-svn: 129735

Add BumpPtrAllocator::getTotalMemory() to allow clients to query how much memory a BumpPtrAllocator allocated.

llvm-svn: 129727

Remove test to check line numbers. There are other numerous tests in our test harness to check line number information. 

llvm-svn: 129725

llvm-svn: 129723

true on success and false on failure. Update callers.

llvm-svn: 129722

llvm-svn: 129720

small heap-allocated SmallString because it unconditionally forces a malloc.

(Revised version of r129688, with the necessary flush() call.)

llvm-svn: 129716

llvm-svn: 129715

the spilled register.

This is quite common on ARM now that some stores have early-clobber defines.

llvm-svn: 129714

superclass variable is instantiated properly.

llvm-svn: 129713