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

stack.

llvm-svn: 103813

llvm-svn: 103808

llvm-svn: 103804

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

argument, like "int $4", to not get an Assertion error.

llvm-svn: 103791

llvm-svn: 103778

llvm-svn: 103776

Patch by Dimitry Andric!

llvm-svn: 103727

after testing before committing.

llvm-svn: 103681

llvm-svn: 103677

lower them to the correct x86-64 instructions since we 
don't have a clean way to handle this in td files yet.
rdar://7947184

llvm-svn: 103668

part first.  rdar://7947184

llvm-svn: 103660

llvm-svn: 103535

be diced into atoms, and adjust getAtom() to take this into account.
 - This fixes relocations to symbols in fixed size literal sections, for
   example.

llvm-svn: 103532

llvm-svn: 103529

to LLVM_LIBRARY_VISIBILITY and introduce LLVM_GLOBAL_VISIBILITY, which is
the opposite, for future use by dragonegg.

llvm-svn: 103495

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

llvm-svn: 103481

was unused. TargetMachine::getSubtarget() is used instead.

llvm-svn: 103474

changed dllexport code to use EmitBytes instead of EmitRawText, and changed the export option to use /EXPORT: instead of -export: on the windows platform

llvm-svn: 103377

llvm-svn: 103373

patch by Nathan Jeffords!

llvm-svn: 103346

llvm-svn: 103276

patch by Peter Housel!

llvm-svn: 103267

instruction, rather than a location near where the new instruction
is being inserted.

llvm-svn: 103232

 - This fixes "leal 0, %eax", for example.

llvm-svn: 103205