the opcode name.  This gives the optimizer more semantic info.

llvm-svn: 97346

but codegen'd differently.  This really wanted to use some
sort of subreg to get the low 4 bytes of the G8RC register
or something.  However, it's invalid and nothing is testing
it, so I'm just zapping the bogosity.

llvm-svn: 97345

dissatisfying hack.  TODO: Improve it. :)

llvm-svn: 97317

llvm-svn: 97316

llvm-svn: 97315

with getType() == MVT::i32 etc.  Teach it that two different
integer constants are contradictory.  This cuts 1K off the X86
table, down to 98k

llvm-svn: 97314

llvm-svn: 97313

predicates.  For example if we have:

Scope:
  CheckType i32
    ABC
  CheckType f32
    DEF
  CheckType i32
    GHI

Then we know that we can transform this into:
Scope:
  CheckType i32
    Scope
      ABC
      GHI
  CheckType f32
    DEF

This reorders the check for the 'GHI' predicate above
the check for the 'DEF' predidate.  However it is safe to do this
in this situation because we know that a node cannot have both an
i32 and f32 type.

We're now doing more factoring that the old isel did.

llvm-svn: 97312

llvm-svn: 97310

respects -debug-only=something-else.

llvm-svn: 97307

as deeply into the pattern as we can get away with.  In pratice, this 
means "all the way to to the emitter code, but not across 
ComplexPatterns".  This substantially increases the amount of factoring
we get.

llvm-svn: 97305

llvm-svn: 97295

llvm_get_module_provider() was returning a value of the wrong type.

llvm-svn: 97290

of a subtle interation in a loop operating in densemap order.

llvm-svn: 97288

confusing the old MAT variable with the new GlobalType one.  This caused
us to promote the @disp global pointer into:

@disp.body = internal global double*** undef

instead of:

@disp.body = internal global [3 x double**] undef

llvm-svn: 97285

llvm-svn: 97283

llvm-svn: 97279

llvm-svn: 97278

for alignment into the LSDA. If the TType base offset is emitted, then put the
padding there. Otherwise, put it in the call site table length. There will be no
conflict between the two sites when placing the padding in one place.

llvm-svn: 97277

o Parallel addition and subtraction, signed/unsigned
o Miscellaneous operations: QADD, QDADD, QSUB, QDSUB
o Unsigned sum of absolute differences [and accumulate]: USAD8, USADA8
o Signed/Unsigned saturate: SSAT, SSAT16, USAT, USAT16
o Signed multiply accumulate long (halfwords): SMLAL<x><y>
o Signed multiply accumulate/subtract [long] (dual): SMLAD[x], SMLALD[X], SMLSD[X], SMLSLD[X]
o Signed dual multiply add/subtract [long]: SMUAD[X], SMUSD[X]

llvm-svn: 97276

This is possible because F8RC is a subclass of F4RC. We keep FMRSD around so
fextend has a pattern.

Also allow folding of memory operands on FMRSD.

llvm-svn: 97275

llvm-svn: 97273

copied out of the source tree.

llvm-svn: 97270

llvm-svn: 97269

llvm-svn: 97268

longer than 80 columns. This replaces the heavy-handed "textwidth"
mechanism, and makes the trailing-whitespace highlighting lazy so
that it isn't constantly jumping on the user during typing.

llvm-svn: 97267

llvm-svn: 97266

llvm-svn: 97265

llvm-svn: 97264

llvm-svn: 97263

The PowerPC floating point registers can represent both f32 and f64 via the
two register classes F4RC and F8RC. F8RC is considered a subclass of F4RC to
allow cross-class coalescing. This coalescing only affects whether registers
are spilled as f32 or f64.

Spill slots must be accessed with load/store instructions corresponding to the
class of the spilled register. PPCInstrInfo::foldMemoryOperandImpl was looking
at the instruction opcode which is wrong.

X86 has similar floating point register classes, but doesn't try to fold
memory operands, so there is no problem there.

llvm-svn: 97262

llvm-svn: 97261

build with exceptions even if LLVM is built without.

llvm-svn: 97260

llvm-svn: 97259

llvm-svn: 97257

as X86 is currently the only FastISel target.  Per review.

llvm-svn: 97255

llvm-svn: 97252

llvm-svn: 97251

argument of createGVNPass and set it automatically for -O3.

llvm-svn: 97245

llvm-svn: 97236