Fix PR3241: Currently EmitCopyFromReg emits a copy from the physical register to a virtual register unless it requires an expensive cross class copy. That means we are only treating "expensive to copy" register dependency as physical register dependency.
Also future proof the scheduler to handle "normal" physical register dependencies. The code is not exercised yet.

llvm-svn: 62074

llvm-svn: 62073

llvm.memcpy/memset/memmove.  This allows removal of some 
hackish code from basicaa.

llvm-svn: 62071

change.

llvm-svn: 62067

not a random piece of it.  No functionality change.

llvm-svn: 62066

parse them.  tblgen doesn't yet do anything with this info though.

llvm-svn: 62065

compensation for turning off gcc's inliner.  This gets
us closer to the amount of inlining we were getting before.
It is not a win on everything, of course, but seems to
gain overall.

llvm-svn: 62058

llvm-svn: 62056

opcode on each delegation.
Instead the information is cached on construction and the cached flag used thereafter.
Introduced two predicates: isCall and isInvoke.

llvm-svn: 62055

llvm-svn: 62048

not thrilled about 64-bit % in general, so rewrite to use * instead.

llvm-svn: 62047

We should treat vectors as atomic types, not like arrays.

llvm-svn: 62046

canonicalization transform based on duncan's comments:

1) improve the comment about %.
2) within our index loop make sure the offset stays 
   within the *type size*, instead of within the *abi size*.
   This allows us to reason explicitly about landing in tail
   padding and means that issues like non-zero offsets into
   [0 x foo] types don't occur anymore.

llvm-svn: 62045

llvm-svn: 62039

llvm-svn: 62036

llvm-svn: 62035

llvm-svn: 62033

llvm-svn: 62029

llvm-svn: 62025

llvm-svn: 62024

llvm-svn: 62023

llvm-svn: 62022

llvm-svn: 62015

llvm-svn: 62006

llvm-svn: 62005

comprehensive and can support more complex style analysis.

llvm-svn: 62002

llvm-svn: 62000

llvm-svn: 61999

llvm-svn: 61997

llvm-svn: 61995

llvm-svn: 61991

llvm-svn: 61990

llvm-svn: 61989

llvm-svn: 61986

I noticed this in the code compiled for a routine using std::map, which produced
this code:
	%25 = tail call i32 @memcmp(i8* %24, i8* %23, i32 6) nounwind readonly
	%.lobit.i = lshr i32 %25, 31		; <i32> [#uses=1]
	%tmp.i = trunc i32 %.lobit.i to i8		; <i8> [#uses=1]
	%toBool = icmp eq i8 %tmp.i, 0		; <i1> [#uses=1]
	br i1 %toBool, label %bb3, label %bb4
which compiled to:

	call	L_memcmp$stub
	shrl	$31, %eax
	testb	%al, %al
	jne	LBB1_11	## 

with this change, we compile it to:

	call	L_memcmp$stub
	testl	%eax, %eax
	js	LBB1_11

This triggers all the time in common code, with patters like this:

	%169 = and i32 %ply, 1		; <i32> [#uses=1]
	%170 = trunc i32 %169 to i8		; <i8> [#uses=1]
	%toBool = icmp ne i8 %170, 0		; <i1> [#uses=1]

 	%7 = lshr i32 %6, 24		; <i32> [#uses=1]
	%9 = trunc i32 %7 to i8		; <i8> [#uses=1]
	%10 = icmp ne i8 %9, 0		; <i1> [#uses=1]

etc

llvm-svn: 61985

llvm-svn: 61984

jump threading can have bugs, who knew? ;-)

llvm-svn: 61983

llvm-svn: 61982

llvm-svn: 61981

llvm-svn: 61980