Replace all target specific implicit def instructions with a target independent one: TargetInstrInfo::IMPLICIT_DEF.

llvm-svn: 48380

table for nounwind calls.

llvm-svn: 48373

llvm-svn: 48355

Use getIntPtrConstant in a couple places to shorten stuff up
Handle splitting vector shuffles with undefs in the mask

llvm-svn: 48351

Livein copy scheduling fixes: do not coalesce physical register copies, correctly determine the safe location to insert the copies.

llvm-svn: 48348

llvm-svn: 48344

Experimental scheduler change to schedule / coalesce the copies added for function livein's. Take 2008-03-10-RegAllocInfLoop.ll, the schedule looks like this after these copies are inserted:

entry: 0x12049d0, LLVM BB @0x1201fd0, ID#0:
Live Ins: %EAX %EDX %ECX
        %reg1031<def> = MOVPC32r 0
        %reg1032<def> = ADD32ri %reg1031, <es:_GLOBAL_OFFSET_TABLE_>, %EFLAGS<imp-def>
        %reg1028<def> = MOV32rr %EAX
        %reg1029<def> = MOV32rr %EDX
        %reg1030<def> = MOV32rr %ECX
        %reg1027<def> = MOV8rm %reg0, 1, %reg0, 0, Mem:LD(1,1) [0x1201910 + 0]
        %reg1025<def> = MOV32rr %reg1029
        %reg1026<def> = MOV32rr %reg1030
        %reg1024<def> = MOV32rr %reg1028

The copies unnecessarily increase register pressure and it will end up requiring a physical register to be spilled.

With -schedule-livein-copies:
entry: 0x12049d0, LLVM BB @0x1201fa0, ID#0:
Live Ins: %EAX %EDX %ECX
        %reg1031<def> = MOVPC32r 0
        %reg1032<def> = ADD32ri %reg1031, <es:_GLOBAL_OFFSET_TABLE_>, %EFLAGS<imp-def>
        %reg1024<def> = MOV32rr %EAX
        %reg1025<def> = MOV32rr %EDX
        %reg1026<def> = MOV32rr %ECX
        %reg1027<def> = MOV8rm %reg0, 1, %reg0, 0, Mem:LD(1,1) [0x12018e0 + 0]

Much better!

llvm-svn: 48307

the fcopysign expansion from LegalizeDAG to get rid of
what seems to be a bug: the use of sign extension means
that when copying the sign bit from an f32 to an f64,
the upper 32 bits of the f64 (now an i64) are set, not
just the top bit...  I also generalized it to work for
any sized floating point types, and removed the bogosity:
  SDOperand Mask1 = (SrcVT == MVT::f64)
    ? DAG.getConstantFP(BitsToDouble(1ULL << 63), SrcVT)
    : DAG.getConstantFP(BitsToFloat(1U << 31), SrcVT);
  Mask1 = DAG.getNode(ISD::BIT_CONVERT, SrcNVT, Mask1);
(here SrcNVT is an integer with the same size as SrcVT).
As far as I can see this takes a 1 << 63, converts to
a double, converts that to a floating point constant
then converts that to an integer constant, ending up
with... 1 << 63 as an integer constant!  So I just
generate this integer constant directly.

llvm-svn: 48305

llvm-svn: 48295

getCopyToParts problem was noticed by the new
LegalizeTypes infrastructure.  In order to avoid
this kind of thing in the future I've added a
check that EXTRACT_ELEMENT is only used with
integers.  Once LegalizeTypes is up and running
most likely BUILD_PAIR and EXTRACT_ELEMENT can
be removed, in favour of using apints instead.

llvm-svn: 48294

X86 lowering normalize vector 0 to v4i32. However DAGCombine can fold (sub x, x) -> 0 after legalization. It can create a zero vector of a type that's not expected (e.g. v8i16). We don't want to disable the optimization since leaving a (sub x, x) is really bad. Add isel patterns for other types of vector 0 to ensure correctness. It's highly unlikely to happen other than in bugpoint reduced test cases.

llvm-svn: 48279

llvm-svn: 48274

llvm-svn: 48257

llvm-svn: 48245

llvm-svn: 48244

llvm-svn: 48223

When the register allocator runs out of registers, spill a physical register around the def's and use's of the interval being allocated to make it possible for the interval to target a register and spill it right away and restore a register for uses. This likely generates terrible code but is before than aborting.

llvm-svn: 48218

enhancements.

llvm-svn: 48215

into:

_test:
	fldz
	ret

instead of:

_test:
	subl	$12, %esp
	#IMPLICIT_DEF %xmm0
	movsd	%xmm0, (%esp)
	fldl	(%esp)
	addl	$12, %esp
	ret

llvm-svn: 48213

llvm-svn: 48208

and it's the result that requires expansion. This code is a little confusing
because the TargetLoweringInfo tables for [US]INT_TO_FP use the operand type
(the integer type) rather than the result type. 

llvm-svn: 48206

verify the register constraint matches what the instruction expects.

llvm-svn: 48205

llvm-svn: 48201

llvm-svn: 48196

llvm-svn: 48194

llvm-svn: 48189

zero extension when checking if an unsigned multiply is
safe.

llvm-svn: 48171

llvm-svn: 48170

llvm-svn: 48169

llvm-svn: 48167

return ValueType can depend its operands' ValueType.

This is a cosmetic change, no functionality impacted.

llvm-svn: 48145

llvm-svn: 48140

Avoid creating BUILD_VECTOR of all zero elements of "non-normalized" type (e.g. v8i16 on x86) after legalizer. Instruction selection does not expect to see them. In all likelihood this can only be an issue in a bugpoint reduced test case.

llvm-svn: 48136

Change insert/extract subreg instructions to be able to be used in TableGen patterns.
Use the above features to reimplement an x86-64 pseudo instruction as a pattern.

llvm-svn: 48130

field to 32 bits, thus enabling correct handling of ByVal
structs bigger than 0x1ffff.  Abstract interface a bit.
Fixes gcc.c-torture/execute/pr23135.c and 
gcc.c-torture/execute/pr28982b.c in gcc testsuite (were ICE'ing
on ppc32, quietly producing wrong code on x86-32.)

llvm-svn: 48122

llvm-svn: 48117

they are produced by calls (which are known exact) and by cross block copies
which are known to be produced by extends.

This improves:

define double @test2() {
	%tmp85 = call double asm sideeffect "fld0", "={st(0)}"()
	ret double %tmp85
}

from:

_test2:
	subl	$20, %esp
	# InlineAsm Start
	fld0
	# InlineAsm End
	fstpl	8(%esp)
	movsd	8(%esp), %xmm0
	movsd	%xmm0, (%esp)
	fldl	(%esp)
	addl	$20, %esp
	#FP_REG_KILL
	ret

to:

_test2:
	# InlineAsm Start
	fld0
	# InlineAsm End
	#FP_REG_KILL
	ret

by avoiding a f64 <-> f80 trip

llvm-svn: 48108

an RFP register class.

Teach ScheduleDAG how to handle CopyToReg with different src/dst 
reg classes.

This allows us to compile trivial inline asms that expect stuff
on the top of x87-fp stack.

llvm-svn: 48107

in different register classes, e.g. copy of ST(0) to RFP*.  This gets
some really trivial inline asm working that plops things on the top of
stack (PR879)

llvm-svn: 48105

llvm-svn: 48100