| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
SelectionDAG's 'init' has not been called when the SelectionDAGBuilder is
constructed (in SelectionDAGISel's constructor), so this was previously always
initialized with 0.
llvm-svn: 162333
|
|
|
|
|
|
|
|
|
|
| |
Even looking at the revision history I couldn't quite piece together why this
cast was ever written in the first place, but I assume it was because of some
change in the inheritance, perhaps this function was reimplemented in a
derived type & this caller was meant to get the base version (& it wasn't
virtual)?
llvm-svn: 162301
|
|
|
|
|
|
| |
PR9673
llvm-svn: 162284
|
|
|
|
|
|
|
|
|
|
|
|
| |
The getSumForBlock function was quadratic in the number of successors
because getSuccWeight would perform a linear search for an already known
iterator.
This patch was originally committed as r161460, but reverted again
because of assertion failures. Now that duplicate Machine CFG edges have
been eliminated, this works properly.
llvm-svn: 162233
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
IR that hasn't been through SimplifyCFG can look like this:
br i1 %b, label %r, label %r
Make sure we don't create duplicate Machine CFG edges in this case.
Fix the machine code verifier to accept conditional branches with a
single CFG edge.
llvm-svn: 162230
|
|
|
|
|
|
|
| |
This pass often has weird CFG hacks and hand-written MI building code
that can go wrong in many ways.
llvm-svn: 162224
|
|
|
|
|
|
|
| |
Verify that the predecessor and successor lists are consistent and free
of duplicates.
llvm-svn: 162223
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The DAGCombiner tries to optimise a BUILD_VECTOR by checking if it
consists purely of get_vector_elts from one or two source vectors. If
so, it either makes a concat_vectors node or a shufflevector node.
However, it doesn't check the element type width of the underlying
vector, so if you have this sequence:
Node0: v4i16 = ...
Node1: i32 = extract_vector_elt Node0
Node2: i32 = extract_vector_elt Node0
Node3: v16i8 = BUILD_VECTOR Node1, Node2, ...
It will attempt to:
Node0: v4i16 = ...
NewNode1: v16i8 = concat_vectors Node0, ...
Where this is actually invalid because the element width is completely
different. This causes an assertion failure on DAG legalization stage.
Fix:
If output item type of BUILD_VECTOR differs from input item type.
Make concat_vectors based on input element type and then bitcast it to the output vector type. So the case described above will transformed to:
Node0: v4i16 = ...
NewNode1: v8i16 = concat_vectors Node0, ...
NewNode2: v16i8 = bitcast NewNode1
llvm-svn: 162195
|
|
|
|
|
|
|
|
|
| |
operations
so other unexpected operations don't slip through. Based on patch by Logan Chien.
PR11786/PR13186.
llvm-svn: 162146
|
|
|
|
|
|
| |
<rdar://problem/10545247>
llvm-svn: 162131
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
make it more consistent with its intended semantics.
The `linker_private_weak_def_auto' linkage type was meant to automatically hide
globals which never had their addresses taken. It has nothing to do with the
`linker_private' linkage type, which outputs the symbols with a `l' (ell) prefix
among other things.
The intended semantic is more like the `linkonce_odr' linkage type.
Change the name of the linkage type to `linkonce_odr_auto_hide'. And therefore
changing the semantics so that it produces the correct output for the linker.
Note: The old linkage name `linker_private_weak_def_auto' will still parse but
is not a synonym for `linkonce_odr_auto_hide'. This should be removed in 4.0.
<rdar://problem/11754934>
llvm-svn: 162114
|
|
|
|
|
|
| |
legalizer may call us with an overly large type.
llvm-svn: 162101
|
|
|
|
|
|
|
|
|
| |
Increment the MBB iterator at the top of the loop to properly handle the
current (and previous) instructions getting erased.
This fixes PR13625.
llvm-svn: 162099
|
|
|
|
|
|
|
|
|
|
|
|
| |
Select instructions pick one of two virtual registers based on a
condition, like x86 cmov. On targets like ARM that support predication,
selects can sometimes be eliminated by predicating the instruction
defining one of the operands.
Teach PeepholeOptimizer to recognize select instructions, and ask the
target to optimize them.
llvm-svn: 162059
|
|
|
|
|
|
| |
pointer.
llvm-svn: 161919
|
|
|
|
|
|
| |
change.
llvm-svn: 161853
|
|
|
|
| |
llvm-svn: 161851
|
|
|
|
|
|
| |
various rounding modes. Use this to implement SelectionDAG constant folding of FFLOOR, FCEIL, and FTRUNC.
llvm-svn: 161807
|
|
|
|
| |
llvm-svn: 161805
|
|
|
|
| |
llvm-svn: 161804
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It never does anything when running 'make check', and it get's in the
way of updating live intervals in 2-addr.
The hook was originally added to help form IT blocks in Thumb2 code
before register allocation, but the pass ordering has changed since
then, and we run if-conversion after register allocation now.
When the MI scheduler is enabled, there will be no less than two
schedulers between 2-addr and Thumb2ITBlockPass, so this hook is
unlikely to help anything.
llvm-svn: 161794
|
|
|
|
| |
llvm-svn: 161788
|
|
|
|
| |
llvm-svn: 161783
|
|
|
|
| |
llvm-svn: 161782
|
|
|
|
|
|
|
|
| |
It is still possible to if-convert if the tail block has extra
predecessors, but the tail phis must be rewritten instead of being
removed.
llvm-svn: 161781
|
|
|
|
|
|
| |
already.
llvm-svn: 161729
|
|
|
|
|
|
|
|
| |
be CSE'd safely.
This is common e.g. when doing rip-relative addressing on x86_64.
llvm-svn: 161728
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Detect when there is not enough available ILP, so if-conversion can't
speculate instructions for free.
Compute the lengthening of the critical path when inserting a select
instruction that depends on the condition as well as both sides of the
if.
Reject conversions that would stretch the critical path by more than
half a mispredict penalty.
llvm-svn: 161713
|
|
|
|
| |
llvm-svn: 161712
|
|
|
|
|
|
|
|
|
|
|
| |
Trace::getResourceLength() computes the number of cycles required to
execute the trace when ignoring data dependencies. The number can be
compared to the critical path to estimate the trace ILP.
Trace::getPHIDepth() computes the data dependency depth of a PHI in a
trace successor that isn't necessarily part of the trace.
llvm-svn: 161711
|
|
|
|
|
|
| |
They identify the PHI predecessors in both diamonds and triangles.
llvm-svn: 161689
|
|
|
|
|
|
|
|
|
| |
When a trace ends with a back-edge, include PHIs in the loop header in
the height computations. This makes the critical path through a loop
more accurate by including the latencies of the last instructions in the
loop.
llvm-svn: 161688
|
|
|
|
|
|
|
|
| |
When replacing Old with New, it can happen that New is already a
successor. Add the old and new edge weights instead of creating a
duplicate edge.
llvm-svn: 161653
|
|
|
|
|
|
|
| |
No changes to these patches, MRI needed to be notified when changing
uses into defs and vice versa.
llvm-svn: 161644
|
|
|
|
|
|
| |
This was the cause of the buildbot failures.
llvm-svn: 161643
|
|
|
|
|
|
| |
These commits broke a number of buildbots.
llvm-svn: 161640
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes it possible to speed up def_iterator by stopping at the first
use. This makes def_empty() and getUniqueVRegDef() much faster when
there are many uses.
In a +Asserts build, LiveVariables is 100x faster in one case because
getVRegDef() has an assertion that would scan to the end of a
def_iterator chain.
Spill weight calculation is significantly faster (300x in one case)
because isTriviallyReMaterializable() calls MRI->isConstantPhysReg(%RIP)
which calls def_empty(%RIP).
llvm-svn: 161634
|
|
|
|
|
|
|
|
|
|
|
| |
Use a more conventional doubly linked list where the Prev pointers form
a cycle. This means it is no longer necessary to adjust the Prev
pointers when reallocating the VRegInfo array.
The test changes are required because the register allocation hint is
using the use-list order to break ties.
llvm-svn: 161633
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Register MachineOperands are kept in linked lists accessible via MRI's
reg_iterator interfaces. The linked list management was handled partly
by MachineOperand methods, partly by MRI methods.
Move all of the list management into MRI, delete
MO::AddRegOperandToRegInfo() and MO::RemoveRegOperandFromRegInfo().
Be more explicit about handling the cases where an MRI pointer isn't
available.
llvm-svn: 161632
|
|
|
|
|
|
|
| |
No test case, the crash only happens when the default use list order is
changed.
llvm-svn: 161627
|
|
|
|
|
|
|
| |
handle the cases where the memory value type was illegal.
PR 13111.
llvm-svn: 161565
|
|
|
|
|
|
| |
That particular optimization was probably premature anyway.
llvm-svn: 161541
|
|
|
|
|
|
|
|
|
|
|
| |
We filter out MachineLoop back-edges during the trace-building PO
traversals, but it is possible to have CFG cycles that aren't natural
loops, and MachineLoopInfo doesn't include such cycles.
Use a standard visited set to detect such CFG cycles, and completely
ignore them when picking traces.
llvm-svn: 161532
|
|
|
|
| |
llvm-svn: 161513
|
|
|
|
|
|
| |
Thanks, Andy!
llvm-svn: 161507
|
|
|
|
| |
llvm-svn: 161470
|
|
|
|
|
|
| |
It caused an assertion failure when compiling consumer-typeset.
llvm-svn: 161463
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We perform the following:
1> Use SUB instead of CMP for i8,i16,i32 and i64 in ISel lowering.
2> Modify MachineCSE to correctly handle implicit defs.
3> Convert SUB back to CMP if possible at peephole.
Removed pattern matching of (a>b) ? (a-b):0 and like, since they are handled
by peephole now.
rdar://11873276
llvm-svn: 161462
|
|
|
|
|
|
|
|
| |
The getSumForBlock function was quadratic in the number of successors
because getSuccWeight would perform a linear search for an already known
iterator.
llvm-svn: 161460
|
|
|
|
| |
llvm-svn: 161454
|