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

llvm-svn: 129768

llvm-svn: 129767

llvm-svn: 129766

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

llvm-svn: 129757

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

llvm-svn: 129750

	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

line tables specify breakpoints can be set in the source. When dumping the
source, the number of breakpoints that can be set on a source line are shown
as a prefix:

(lldb) source list -f test.c -l1 -c222 -b
       1   	#include <stdio.h>
       2   	#include <sys/fcntl.h>
       3   	#include <unistd.h>
       4   	int
       5   	sleep_loop (const int num_secs)
[2]    6   	{
       7   	    int i;
[1]    8   	    for (i=0; i<num_secs; ++i)
       9   	    {
[1]    10  	        printf("%d of %i - sleep(1);\n", i, num_secs);
[1]    11  	        sleep(1);       
       12  	    }
       13  	    return 0;
[1]    14  	}
       15  	
       16  	int 
       17  	main (int argc, char const* argv[])
[1]    18  	{
[1]    19  	    printf("Process: %i\n\n", getpid());
[1]    20  	    puts("Press any key to continue..."); getchar();
[1]    21  	    sleep_loop (20);
       22  	    return 12;
[1]    23  	}

Above we can see there are two breakpoints for line 6 and one breakpoint for
lines 8, 10, 11, 14, 18, 19, 20, 21 and 23. All other lines have no line table
entries for them. This helps visualize the data provided in the debug 
information without having to manually dump all line tables. It also includes
all inline breakpoint that may result for a given file which can also be very
handy to see.

llvm-svn: 129747

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

llvm-svn: 129740

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

llvm-svn: 129734

llvm-svn: 129733

llvm-svn: 129732

$ lldb --arch i386-unknown-unknown a.out

It would then create a target with only the "i386" part due to 
SBDebugger::GetDefaultArchitecture(...) truncating the arch triple due to the
way things used to be.

llvm-svn: 129731

Add libclang API to query how much memory is used by a CXTranslationUnit.  This is a WIP.  Currently we report
the amount used for expressions, types, identifiers, and selectors.

llvm-svn: 129730

Add ASTContext::getTotalMemory() to allow clients to query how much memory is bump allocated for declarations, statements, and types.

llvm-svn: 129729

llvm-svn: 129728

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