| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 165550
|
|
|
|
|
|
|
|
| |
to the data layout for specifying a per address space pointer size.
The next step is to update the optimizers to allow them to optimize the different address spaces with this information.
llvm-svn: 165505
|
|
|
|
|
|
|
| |
We use the enums to query whether an Attributes object has that attribute. The
opaque layer is responsible for knowing where that specific attribute is stored.
llvm-svn: 165488
|
|
|
|
| |
llvm-svn: 165463
|
|
|
|
|
|
|
|
| |
This class is used by LSR and a number of places in the codegen.
This is the first step in de-coupling LSR from TLI, and creating
a new interface in between them.
llvm-svn: 165455
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the CFG contains a loop with multiple entry blocks, the traces
computed by MachineTraceMetrics don't always have the same nice
properties. Loop back-edges are normally excluded from traces, but
MachineLoopInfo doesn't recognize loops with multiple entry blocks, so
those back-edges may be included.
Avoid asserting when that happens by adding an isEarlierInSameTrace()
function that accurately determines if a dominating block is part of the
same trace AND is above the currrent block in the trace.
llvm-svn: 165434
|
|
|
|
| |
llvm-svn: 165427
|
|
|
|
| |
llvm-svn: 165426
|
|
|
|
| |
llvm-svn: 165418
|
|
|
|
|
|
| |
SchedModel
llvm-svn: 165417
|
|
|
|
| |
llvm-svn: 165416
|
|
|
|
| |
llvm-svn: 165402
|
|
|
|
| |
llvm-svn: 165382
|
|
|
|
| |
llvm-svn: 165381
|
|
|
|
| |
llvm-svn: 165331
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 165321
|
|
|
|
| |
llvm-svn: 165267
|
|
|
|
|
|
|
|
|
|
| |
a) frame setup instructions define the prologue
b) we shouldn't change our location mid-stream
Add a test to make sure that the stack adjustment stays within
the prologue.
llvm-svn: 165250
|
|
|
|
|
|
|
| |
Not all targets have itineraries, but the subtarget always has an
MCSchedModel.
llvm-svn: 165236
|
|
|
|
| |
llvm-svn: 165235
|
|
|
|
|
|
| |
allocator. Fixes PR13945.
llvm-svn: 165201
|
|
|
|
| |
llvm-svn: 165188
|
|
|
|
| |
llvm-svn: 165163
|
|
|
|
|
|
|
|
|
|
|
| |
load and
multiple stores with a single load. We create the wide loads and stores (and their chains)
before we remove the scalar loads and stores and fix the DAG chain. We attempted to merge
loads with a different chain. When that happened, the assumption that it is safe to RAUW
broke and a cycle was introduced.
llvm-svn: 165148
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
optimization
is not profitable in many cases because modern processors perform multiple stores
in parallel and merging stores prior to merging requires extra work. We handle two main cases:
1. Store of multiple consecutive constants:
q->a = 3;
q->4 = 5;
In this case we store a single legal wide integer.
2. Store of multiple consecutive loads:
int a = p->a;
int b = p->b;
q->a = a;
q->b = b;
In this case we load/store either ilegal vector registers or legal wide integer registers.
llvm-svn: 165125
|
|
|
|
|
|
| |
not propagate through implicit defs.
llvm-svn: 165102
|
|
|
|
|
|
| |
more detail.
llvm-svn: 165099
|
|
|
|
|
|
|
|
|
|
|
| |
Enable the pass by default for targets that request it, and change the
-enable-early-ifcvt to the opposite -disable-early-ifcvt.
There are still some x86 regressions when enabling early if-conversion
because of the missing machine models. Disable the pass for x86 until
machine models are added.
llvm-svn: 165075
|
|
|
|
|
|
|
| |
This reverts 165055 and 165052 temporarily while I look at debugger
failures.
llvm-svn: 165071
|
|
|
|
|
|
|
| |
The new algorithm has been enabled by default for almost a week now and
seems to be stable.
llvm-svn: 165062
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reserved register live ranges look like a set of dead defs - any uses of
reserved registers are ignored.
Instead of skipping the updating of reserved register operands entirely,
just ignore the use operands and treat the def operands normally.
No test case, handleMove() is not commonly used yet.
llvm-svn: 165060
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
JoinVals::pruneValues() calls LIS->pruneValue() to avoid conflicts when
overlapping two different values. This produces a set of live range end
points that are used to reconstruct the live range (with SSA update)
after joining the two registers.
When a value is pruned twice, the set of end points was insufficient:
v1 = DEF
v1 = REPLACE1
v1 = REPLACE2
KILL v1
The end point at KILL would only reconstruct the live range from
REPLACE2 to KILL, leaving the range REPLACE1-REPLACE2 dead.
Add REPLACE2 as an end point in this case so the full live range is
reconstructed.
This fixes PR13999.
llvm-svn: 165056
|
|
|
|
| |
llvm-svn: 165054
|
|
|
|
|
|
|
| |
prologue. Also skip frame setup instructions when looking for the
first location.
llvm-svn: 165052
|
|
|
|
|
|
|
| |
with just an insert point from the MachineBasicBlock and let
the location be updated as we access it.
llvm-svn: 165049
|
|
|
|
|
|
|
| |
the add/sub case since in the case of multiplication you also have to check that
the operation in the larger type did not overflow.
llvm-svn: 165017
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 164924
|
|
|
|
| |
llvm-svn: 164911
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is not profitable in many cases
because moden processos can store multiple values in parallel, and preparing the consecutive store requires
some work. We only handle these cases:
1. Consecutive stores where the values and consecutive loads. For example:
int a = p->a;
int b = p->b;
q->a = a;
q->b = b;
2. Consecutive stores where the values are constants. Foe example:
q->a = 4;
q->b = 5;
llvm-svn: 164910
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
buildbots. Original commit message:
A DAGCombine optimization for merging consecutive stores. This optimization is not profitable in many cases
because moden processos can store multiple values in parallel, and preparing the consecutive store requires
some work. We only handle these cases:
1. Consecutive stores where the values and consecutive loads. For example:
int a = p->a;
int b = p->b;
q->a = a;
q->b = b;
2. Consecutive stores where the values are constants. Foe example:
q->a = 4;
q->b = 5;
llvm-svn: 164890
|
|
|
|
|
|
| |
operators to end of preceding line. No functional change intended.
llvm-svn: 164887
|
|
|
|
|
|
| |
the varying arguments. No functional change.
llvm-svn: 164886
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
is not profitable in many cases
because moden processos can store multiple values in parallel, and preparing the consecutive store requires
some work. We only handle these cases:
1. Consecutive stores where the values and consecutive loads. For example:
int a = p->a;
int b = p->b;
q->a = a;
q->b = b;
2. Consecutive stores where the values are constants. Foe example:
q->a = 4;
q->b = 5;
llvm-svn: 164885
|
|
|
|
|
|
|
|
|
| |
The new coalescer can turn a full virtual register definition into a
partial redef by merging another value into an unused vector lane.
Make sure to clear the <read-undef> flag on such defs.
llvm-svn: 164807
|
|
|
|
|
|
|
| |
The new coalescer is better at merging values into unused vector lanes,
improving NEON code.
llvm-svn: 164794
|
|
|
|
|
|
|
|
| |
The fix is obvious and the only test case I have is horrible, so I am
not including it. The problem shows up when self-hosting clang on i386
with -new-coalescer enabled.
llvm-svn: 164793
|
|
|
|
|
|
| |
Fixes PR13943.
llvm-svn: 164778
|
|
|
|
|
|
| |
See: http://en.wikipedia.org/wiki/If_and_only_if Commit 164767
llvm-svn: 164768
|
|
|
|
| |
llvm-svn: 164767
|
|
|
|
|
|
|
| |
The hasFnAttr method has been replaced by querying the Attributes explicitly. No
intended functionality change.
llvm-svn: 164725
|