which is faster, simpler, and less surprising.

llvm-svn: 106263

be done incrementally and intermixed with the adding of more
AVX instructions. This is a first step in that direction

llvm-svn: 106251

addresses a longstanding deficiency noted in many FIXMEs scattered
across all the targets.

This effectively moves the problem up one level, replacing eleven
FIXMEs in the targets with eight FIXMEs in CodeGen, plus one path
through FastISel where we actually supply a DebugLoc, fixing Radar
7421831.

llvm-svn: 106243

TLVP:

movl _a@TLVP, %eax

Daniel: Please review if you get a chance.
llvm-svn: 106194

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

flag argument to addReg is not the same format as flags attached
to MachineOperand, although both have the same info.  I don't
think this actually mattered; the bootstrap failure did not
reproduce on the next run anyway.

llvm-svn: 106049

Nelson Elhage!

llvm-svn: 106031

llvm-svn: 105988

containing the target address, an input, into an output.  I don't
think this actually broke anything on x86 (it does on ARM), but
it's wrong.

llvm-svn: 105986

symbols as declarations in the X86 backend.  This would manifest
on darwin x86-32 as errors like this with -fvisibility=hidden:

symbol '__ZNSbIcED1Ev' can not be undefined in a subtraction expression

This fixes PR7353.

llvm-svn: 105954

more clear what exactly is missing.

llvm-svn: 105934

llvm-svn: 105900

llvm-svn: 105876

llvm-svn: 105873

llvm-svn: 105870

Handle OpSize TSFlag for AVX

llvm-svn: 105869

llvm-svn: 105860

Introduce the VEX_X field

llvm-svn: 105859

llvm-svn: 105674

instruction.  Added the 64-bit version "jrcxz" so it is recognized and also
added the checks for incorrect uses of "jcxz" in 64-bit mode and "jrcxz" in
32-bit mode.  Still to do is to correctly handle the encoding of the
instruction adding the Address-size override prefix byte, 0x67, when the width
of the count register is not the same as the mode the machine is running in.
Which for example means the encoding of "jecxz" depends if you are assembling
as a 32-bit target or a 64-bit target.

llvm-svn: 105661

that rip-relative address when executing in 32-bit mode.

llvm-svn: 105656

immediates to avoid breaking the build.

llvm-svn: 105652

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

llvm-svn: 105645

llvm-svn: 105527

In file included from X86InstrInfo.cpp:16:
X86GenInstrInfo.inc:2789: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2790: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2792: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2793: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2808: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2809: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2816: error: integer constant is too large for 'long' type
X86GenInstrInfo.inc:2817: error: integer constant is too large for 'long' type

llvm-svn: 105524

yet, only assembly encoding support.

llvm-svn: 105521

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

llvm-svn: 105509

llvm-svn: 105381

llvm-svn: 105377

llvm-svn: 105376

llvm-svn: 105375

instruction defines subregisters.

Any existing subreg indices on the original instruction are preserved or
composed with the new subreg index.

Also substitute multiple operands mentioning the original register by using the
new MachineInstr::substituteRegister() function. This is necessary because there
will soon be <imp-def> operands added to non read-modify-write partial
definitions. This instruction:

  %reg1234:foo = FLAP %reg1234<imp-def>

will reMaterialize(%reg3333, bar) like this:

  %reg3333:bar-foo = FLAP %reg333:bar<imp-def>

Finally, replace the TargetRegisterInfo pointer argument with a reference to
indicate that it cannot be NULL.

llvm-svn: 105358

llvm-svn: 105344

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

llvm-svn: 105342

mailing list archives.

llvm-svn: 105341

llvm-svn: 105325

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

llvm-svn: 105303

in X86FastISel. Patch by Jan Sjodin.

llvm-svn: 105290