llvm-svn: 106746

bt instruction, which was exposed by r106263.

llvm-svn: 106718

Revert r106263, "Fold the ShrinkDemandedOps pass into the regular DAGCombiner pass,"... it was causing both 'file' (with clang) and 176.gcc (with llvm-gcc) to be miscompiled.

llvm-svn: 106634

to using that.

llvm-svn: 106633

Revert r106066, "Create a more targeted fix for not sinking instructions into a range where it"... it causes bzip2 to be miscompiled by Clang.

Conflicts:

	lib/CodeGen/MachineSink.cpp

llvm-svn: 106614

llvm-svn: 106574

llvm-svn: 106405

SDNode *, since it doesn't care about the ResNo value.

llvm-svn: 106282

llvm-svn: 106280

llvm-svn: 106279

llvm-svn: 106278

which is faster, simpler, and less surprising.

llvm-svn: 106263

will conflict with another live range. The place which creates this scenerio is
the code in X86 that lowers a select instruction by splitting the MBBs. This
eliminates the need to check from the bottom up in an MBB for live pregs.

llvm-svn: 106066

a relative address.

llvm-svn: 106064

the register.  While we're at it, make sure it's in the right one.

llvm-svn: 105645

I don't think this ever resulted in problems on x86, but it
would on ARM.

llvm-svn: 105509

llvm-svn: 105381

backend.  Add a FIXME noting what can be fixed here.

llvm-svn: 105342

mailing list archives.

llvm-svn: 105341

x86 backend currently doesn't know how to handle them.

This doesn't really fix anything because LegalizeTypes doesn't know how to
handle them either.  We do get a better error message, though.

llvm-svn: 105305

Fix PR7193: if sibling call address can take a register, make sure there are enough registers available by counting inreg arguments.

llvm-svn: 105092

llvm-svn: 105059

No functional effect as these nodes are not generated yet.

llvm-svn: 104879

To support this, move IsCalleePop from X86ISelLowering to X86Subtarget.

llvm-svn: 104866

llvm-svn: 104691

llvm-svn: 104421

llvm-svn: 104337

Case where MMX is disabled wasn't handled right.
MMX->MMX bitconverts are Legal.

llvm-svn: 104336

tricky since there's a 3rd 64-bit type, MMX vectors.
PR 7135.

llvm-svn: 104308

Code refactoring: pull SchedPreference enum from TargetLowering.h to TargetMachine.h and put it in its own namespace.

llvm-svn: 104147

<1xi64> -> i64 to work in MMX registers on hosts where -no-sse
is the default (not mine).  The right thing is
to accept this and make i64->f64 conversions go through memory,
but I don't have time right now.

llvm-svn: 103914

(This worked as of about 6 months ago and I didn't track down
exactly what broke it; I think this fix is appropriate.)

llvm-svn: 103911

Patch by Charles Davis and Steven Watanabe!

llvm-svn: 103902

The implementation in LegalizeIntegerTypes to handle this as 
sint64->float + appropriate power of 2 is subject to double rounding,
considered incorrect by numerics people.  Use this implementation only
when it is safe.  This leads to using library calls in some cases
that produced inline code before, but it's correct now.
(EVTToAPFloatSemantics belongs somewhere else, any suggestions?)

Add a correctly rounding (though not particularly fast) conversion
that uses X87 80-bit computations for x86-32.

7885399, 5901940.  This shows up in gcc.c-torture/execute/ieee/rbug.c
in the gcc testsuite on some platforms.

llvm-svn: 103883

the variable actually tracks.

N.B., several back-ends are using "HasCalls" as being synonymous for something
that adjusts the stack. This isn't 100% correct and should be looked into.

llvm-svn: 103802

used more than once. If ISel had put a kill flag on one of them,
it's not valid to transfer the kill flag to each new instance.

llvm-svn: 103799

Move EmitTargetCodeForMemcpy, EmitTargetCodeForMemset, and
EmitTargetCodeForMemmove out of TargetLowering and into
SelectionDAGInfo to exercise this.

llvm-svn: 103481

changes before doing phi lowering for switches.

llvm-svn: 102809

on the original variables, so it's easier to see what is being done
to which blocks.

llvm-svn: 102759

llvm-svn: 102730