by having X86DAGToDAGISel::SelectAddr get passed in the parent node
of the operand match (the load/store/atomic op) and having it get
the address space from that, instead of having special FS/GS addr
mode operations that require duplicating the entire instruction set
to support.

This makes FS and GS relative accesses *far* more predictable and
work much better.  It also simplifies the X86 backend a bit, more
to come.

There is still a pending issue with nodes like ISD::PREFETCH and
X86ISD::FLD, which really should be MemSDNode's but aren't.

llvm-svn: 114491

the predicate to discover the number of sign bits.  Enhance X86's target lowering to provide
a useful response to this query.

llvm-svn: 114473

passed the root of the match, even though only a few patterns
actually needed this (one in X86, several in ARM [which should
be refactored anyway], and some in CellSPU that I don't feel 
like detangling).   Instead of requiring all ComplexPatterns to
take the dead root, have targets opt into getting the root by
putting SDNPWantRoot on the ComplexPattern.

llvm-svn: 114471

llvm-svn: 114468

llvm-svn: 114463

llvm-svn: 114461

(sbbl x, x) sets the registers to 0 or ~0.  Combined with two's complement arithmetic, we can fold
the intermediate AND and the ADD into a single SUB.

This fixes <rdar://problem/8449754>.

llvm-svn: 114460

and store intrinsics are represented with MemIntrinsicSDNodes.

llvm-svn: 114454

llvm-svn: 114453

MachinePointerInfo around more.

llvm-svn: 114452

SelectionDAG::getExtLoad overload, and eliminate it.

llvm-svn: 114446

llvm-svn: 114445

I am unable to write a test for this case, help is solicited, though...
What I did is to tickle the code in the debugger and verify that we do the right thing.

llvm-svn: 114430

into OptimizeCompareInstr.
This necessitates the passing of CmpValue around,
so widen the virtual functions to accomodate.

No functionality changes.

llvm-svn: 114428

llvm-svn: 114410

"getFixedStack" on the MachinePointerInfo class.  While
this isn't the problem I'm setting out to solve, it is the
right way to eliminate PseudoSourceValue, so lets go with it.

llvm-svn: 114406

of the getLoad methods.  This fixes at least one bug where an incorrect
svoffset is passed in (a potential combiner-aa miscompile).

llvm-svn: 114404

into non-segment-relative copies.

llvm-svn: 114402

instead of srcvalue/offset pairs.  This corrects SV info for mem 
operations whose size is > 32-bits.

llvm-svn: 114401

llvm-svn: 114391

For now, just disable folding the load into the call.

llvm-svn: 114386

between the high and low registers for prologue/epilogue code. This was
a Darwin-only thing that wasn't providing a realistic benefit anymore.
Combining the save areas simplifies the compiler code and results in better
ARM/Thumb2 codegen.

For example, previously we would generate code like:
        push    {r4, r5, r6, r7, lr}
        add     r7, sp, #12
        stmdb   sp!, {r8, r10, r11}
With this change, we combine the register saves and generate:
        push    {r4, r5, r6, r7, r8, r10, r11, lr}
        add     r7, sp, #12

rdar://8445635

llvm-svn: 114340

llvm-svn: 114304

llvm-svn: 114303

llvm-svn: 114297

Patch by Che-Liang Chiou <clchiou@gmail.com>!

llvm-svn: 114294

llvm-svn: 114292

llvm-svn: 114263

thumb with floating point.

llvm-svn: 114256

llvm-svn: 114254

instructions (PICADD, PICLDR, et.al.)

llvm-svn: 114243

with one in the generic printing code is an error.

llvm-svn: 114242

llvm-svn: 114240

llvm-svn: 114237

value should be in GPRs when it's going to be used as a scalar, and we use
VMOVRRD to make that happen, but if the value is converted back to a vector
we need to fold to a simple bit_convert.  Radar 8407927.

llvm-svn: 114233

and shift instructions on ARM. Update the tests to match.

llvm-svn: 114230

llvm-svn: 114226

llvm-svn: 114215

llvm-svn: 114212

This fixes rdar://8396318.

llvm-svn: 114201