llvm-svn: 104452

llvm-svn: 104435

llvm-svn: 104421

llvm-svn: 104394

that are aliases of the specified register.
- Rename modifiesRegister to definesRegister since it's looking a def of the
specific register or one of its super-registers. It's not looking for def of a
sub-register or alias that could change the specified register.
- Added modifiesRegister to look for defs of aliases.

llvm-svn: 104377

llvm-svn: 104337

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

llvm-svn: 104336

pass after isel instead of being interlaced with it, we can
trust that all the code for a function has been isel'd before
it is run.

The practical impact of this is that we can scan for machine
instr phis instead of doing a fuzzy match on the LLVM BB for
phi nodes.  Doing the fuzzy match required knowing when isel
would produce an fp reg stack phi which was gross.  It was
also wrong in cases where select got lowered to a branch
tree because cmovs aren't available (PR6828).

Just do the scan on machine phis which is simpler, faster
and more correct.  This fixes PR6828.

llvm-svn: 104333

llvm-svn: 104331

llvm-svn: 104330

eliminating the gymnastics around the ContainsFPCode var.

llvm-svn: 104328

llvm-svn: 104326

isn't ideal if we want to be able to use another object file format.

Add a createObjectStreamer() factory method so that the correct object
file streamer can be instantiated for a given target triple.

llvm-svn: 104318

differently. This will make adding ELF support easier in the long run.

llvm-svn: 104317

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

llvm-svn: 104308

llvm-svn: 104275

llvm-svn: 104272

llvm-svn: 104271

have a pattern and it had an invalid encoding.

llvm-svn: 104244

instructions.

llvm-svn: 104231

16-bit and 32-bit pushf and popf.

llvm-svn: 104228

llvm-svn: 104204

doesn't have a register operand. Also, use I instead of PSI, for
consistency with mfence and lfence.

llvm-svn: 104203

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

llvm-svn: 104147

llvm-svn: 104122

prefix byte problem as in r104062.
 - As a total hack to keep the TAILCALL markers in the output, which some tests depend on, this invents a new TAILJMP_1 instruction.

llvm-svn: 104120

CALL64pcrel32, for the same reason.

llvm-svn: 104116

llvm-svn: 104112

avoid same prefix byte problem as in r104062.

llvm-svn: 104108

opcodes into a helper function. This fixes a few places in the code
which were not properly selecting the 8-bit-immediate opcodes.

llvm-svn: 104091

llvm-svn: 104068

8-bit immediate field rather than one with a wider immediate field.

llvm-svn: 104064

The register use operands (e.g. the first argument is passed in a 
register) is currently being modeled as a normal register use,
instead of correctly being an implicit use.  This causes the operand
to get propagated onto the mcinst, which was causing the encoder to
emit a rex prefix byte, which generates an invalid call.

This fixes rdar://7998435

llvm-svn: 104062

  X86::ADC32ri $0, %eax
to
  X86::ADC32i32 $0

llvm-svn: 104030

llvm-svn: 103974

<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

of "has calls". That's probably wrong, but it needs further
investigation. Revert to the original behavior until this is settled.

llvm-svn: 103824