Age | Commit message (Collapse) | Author |
|
operations
so other unexpected operations don't slip through. Based on patch by Logan Chien.
PR11786/PR13186.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162146 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
<rdar://problem/10545247>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162131 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162114 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
legalizer may call us with an overly large type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162101 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Increment the MBB iterator at the top of the loop to properly handle the
current (and previous) instructions getting erased.
This fixes PR13625.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162099 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162059 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
pointer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161919 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161853 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161851 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
various rounding modes. Use this to implement SelectionDAG constant folding of FFLOOR, FCEIL, and FTRUNC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161807 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161805 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161804 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161794 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161788 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161783 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161782 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161781 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
already.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161729 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
be CSE'd safely.
This is common e.g. when doing rip-relative addressing on x86_64.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161728 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161713 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161712 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161711 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
They identify the PHI predecessors in both diamonds and triangles.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161689 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161688 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161653 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
No changes to these patches, MRI needed to be notified when changing
uses into defs and vice versa.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161644 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This was the cause of the buildbot failures.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161643 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
These commits broke a number of buildbots.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161640 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161634 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161633 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161632 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
No test case, the crash only happens when the default use list order is
changed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161627 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
handle the cases where the memory value type was illegal.
PR 13111.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161565 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
That particular optimization was probably premature anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161541 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161532 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161513 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Thanks, Andy!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161507 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161470 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
It caused an assertion failure when compiling consumer-typeset.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161463 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161462 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
The getSumForBlock function was quadratic in the number of successors
because getSuccWeight would perform a linear search for an already known
iterator.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161460 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161454 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
This adds support for TargetIndex operands during isel. The meaning of
these (index, offset, flags) operands is entirely defined by the target.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161453 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
character arrays. This is in line with what GCC does.
<rdar://problem/10529227>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161446 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
A target index operand looks a lot like a constant pool reference, but
it is completely target-defined. It contains the 8-bit TargetFlags, a
32-bit index, and a 64-bit offset. It is preserved by all code generator
passes.
TargetIndex operands can be used to carry target-specific information in
cases where immediate operands won't suffice.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161441 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161437 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Compare the critical paths of the two traces through an if-conversion
candidate. If the difference is larger than the branch brediction
penalty, reject the if-conversion. If would never pay.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161433 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Previously, MBP essentially aligned every branch target it could. This
bloats code quite a bit, especially non-looping code which has no real
reason to prefer aligned branch targets so heavily.
As Andy said in review, it's still a bit odd to do this without a real
cost model, but this at least has much more plausible heuristics.
Fixes PR13265.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161409 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
If the result of a common subexpression is used at all uses of the candidate
expression, CSE should not increase the live range of the common subexpression.
rdar://11393714 and rdar://11819721
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161396 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
TwoAddressInstructionPass doesn't remat any more.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161285 91177308-0d34-0410-b5e6-96231b3b80d8
|