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

llvm-svn: 97235

stuff to emit optimal nops in the right places.

llvm-svn: 97233

present in the module.

llvm-svn: 97232

llvm-svn: 97231

llvm-svn: 97230

llvm-svn: 97229

llvm-svn: 97228

llvm-svn: 97227

Previously LoopStrengthReduce would sometimes be unable to find
a legal formula, causing an assertion failure.

llvm-svn: 97226

llvm-svn: 97220

llvm-svn: 97219

gross little neighbor merging implementation.  This one has
the benefit of not violating the ordering of patterns, so it
generates code that passes tests again.

llvm-svn: 97218

llvm-svn: 97217

llvm-svn: 97216

current design.  This generates a matcher that successfully
runs, but it turns out that the factoring we're doing violates
the ordering of patterns, so we end up matching (e.g.) movups
where we want movaps.  This won't due, but I'll address this in
a follow on patch.  It's nice to not be on by default yet! :)

llvm-svn: 97215

that we never return a tombstone value, which (thankfully) triggers an
assert in densemap.

llvm-svn: 97214

object construction. There is no provision to change them when the 
code for a function generated. 
So we have to change these names while printing assembly.

llvm-svn: 97213

and restore the entire matcher stack by value.  This is because children
we're testing could do moveparent or other things besides just 
scribbling on additions to the stack.

llvm-svn: 97212

llvm-svn: 97211

llvm-svn: 97208