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

llvm-svn: 105645

llvm-svn: 105634

Discussed here:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-June/032107.html

llvm-svn: 105601

llvm-svn: 105591

- change isShuffleMaskLegal to show that all shuffles with 32-bit and 64-bit
  elements are legal
- the Neon shuffle instructions do not support 64-bit elements, but we were
  not checking for that before lowering shuffles to use them
- remove some 64-bit element vduplane patterns that are no longer needed

llvm-svn: 105586

rdar://7797940

llvm-svn: 105557

encapsulation to force the users of these classes to know about the internal
data structure of the Operands structure. It also can lead to errors, like in
the MSIL writer.

llvm-svn: 105539

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

unless using -arm-tail-calls.

llvm-svn: 105515

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

llvm-svn: 105509

8060143, although this doesn't fix the real problem with tail call.

llvm-svn: 105472

llvm-svn: 105470

llvm-svn: 105454

llvm-svn: 105441

VECTOR_SHUFFLEs to REG_SEQUENCE instructions.  The standard ISD::BUILD_VECTOR
node corresponds closely to REG_SEQUENCE but I couldn't use it here because
its operands do not get legalized.  That is pretty awful, but I guess it
makes sense for other targets.  Instead, I have added an ARM-specific version
of BUILD_VECTOR that will have its operands properly legalized.
This fixes the rest of Radar 7872877.

llvm-svn: 105439

llvm-svn: 105427

A temporary flag -arm-tail-calls defaults to off,
so there is no functional change by default.
Intrepid users may try this; simple cases work
but there are bugs.

llvm-svn: 105413

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: 105350

llvm-svn: 105344

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

llvm-svn: 105342

mailing list archives.

llvm-svn: 105341

and tidy up the comment describing it.

llvm-svn: 105339

llvm-svn: 105335

llvm-svn: 105325

llvm-svn: 105322

backends and removes the virtual declaration. With that out of the way
I should be able to cleanup one backend at a time.

llvm-svn: 105321

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

llvm-svn: 105276

llvm-svn: 105269

llvm-svn: 105109

llvm-svn: 105108