| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 114531
|
| |
|
|
|
|
| |
SegmentBaseAddress.
llvm-svn: 114529
|
| |
|
|
| |
llvm-svn: 114528
|
| |
|
|
|
|
|
|
|
| |
-This line, and those below, will be ignored--
M test/MC/AsmParser/X86/x86_instructions.s
M lib/Target/X86/AsmParser/X86AsmParser.cpp
llvm-svn: 114527
|
| |
|
|
| |
llvm-svn: 114526
|
| |
|
|
| |
llvm-svn: 114523
|
| |
|
|
|
|
| |
can access the stack due to how it is generated though.
llvm-svn: 114522
|
| |
|
|
|
|
| |
used with stack slots, but hey, lets be safe.
llvm-svn: 114521
|
| |
|
|
| |
llvm-svn: 114515
|
| |
|
|
|
|
| |
call through gs-relative memory now.
llvm-svn: 114510
|
| |
|
|
|
|
| |
256/257
llvm-svn: 114508
|
| |
|
|
|
|
| |
when the 'and' instruction is after the comparison.
llvm-svn: 114506
|
| |
|
|
|
|
| |
the rest of it is next up.
llvm-svn: 114500
|
| |
|
|
|
|
|
|
| |
this makes
irrelevant, but add a new test for the new, improved functionality.
llvm-svn: 114494
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
target-dependent, by using
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
|
| |
|
|
|
|
|
|
|
|
|
| |
carry-materialization
(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
|
| |
|
|
|
|
|
|
| |
relative operations
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
|