lower XMM register gets in first. This will allow the SUBREG pattern to
elliminate the first vector insertion.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137310 91177308-0d34-0410-b5e6-96231b3b80d8
(for example, after integer operation), do not pack the registers into a YMM
before saving. Its better to save as two XMM registers.
Before:
vinsertf128 $1, %xmm3, %ymm0, %ymm3
vinsertf128 $0, %xmm1, %ymm3, %ymm1
vmovaps %ymm1, 416(%rsp)
After:
vmovaps %xmm3, 416+16(%rsp)
vmovaps %xmm1, 416(%rsp)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137308 91177308-0d34-0410-b5e6-96231b3b80d8
An algorithm for incrementally updating LoopInfo within a
LoopPassManager. The incremental update should be extremely cheap in
most cases and can be used in places where it's not feasible to
regenerate the entire loop forest.
- "Unloop" is a node in the loop tree whose last backedge has been removed.
- Perform reverse dataflow on the block inside Unloop to propagate the
nearest loop from the block's successors.
- For reducible CFG, each block in unloop is visited exactly
once. This is because unloop no longer has a backedge and blocks
within subloops don't change parents.
- Immediate subloops are summarized by the nearest loop reachable from
their exits or exits within nested subloops.
- At completion the unloop blocks each have a new parent loop, and
each immediate subloop has a new parent.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137276 91177308-0d34-0410-b5e6-96231b3b80d8
data in-register prior to saving to memory. When we reorder the data in memory
we prevent the need to save multiple scalars to memory, making a single regular
store.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137238 91177308-0d34-0410-b5e6-96231b3b80d8
Also, my apologies for spoiling the autocomplete on SimplifyInstructions.cpp. I couldn't think of a better filename.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137229 91177308-0d34-0410-b5e6-96231b3b80d8
def : Pat<(X86Movss VR128:$src1,
(bc_v4i32 (v2i64 (load addr:$src2)))),
(MOVLPSrm VR128:$src1, addr:$src2)>;
This matches a MOVSS dag with a MOVLPS instruction. However, MOVSS will replace only the low 32 bits of the register, while the MOVLPS instruction will replace the low 64 bits. A testcase is added and illustrates the bug and also modified the one that was already present. Patch by Tanya Lattner.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137227 91177308-0d34-0410-b5e6-96231b3b80d8
based on ScalarEvolution without changing the induction variable phis.
This utility is the main tool of IndVarSimplifyPass, but the pass also
restructures induction variables in strange ways that are sensitive to
pass ordering. This provides a way for other loop passes to simplify
new uses of induction variables created during transformation. The
utility may be used by any pass that preserves ScalarEvolution. Soon
LoopUnroll will use it.
The net effect in this checkin is to cleanup the IndVarSimplify pass
by factoring out the SimplifyIndVar algorithm into a standalone utility.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137197 91177308-0d34-0410-b5e6-96231b3b80d8
These are not individual bug fixes. I had to rewrite a good chunk of
the unroller to make it sane. I think it was getting lucky on trivial
completely unrolled loops with no early exits. I included some fairly
simple unit tests for partial unrolling. I didn't do much stress
testing, so it may not be perfect, but should be usable now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137190 91177308-0d34-0410-b5e6-96231b3b80d8
On Cortex-A8, we use the NEON v2f32 instructions for f32 arithmetic. For
better latency, we also send D-register copies down the NEON pipeline by
translating them to vorr instructions.
This patch promotes even S-register copies to D-register copies when
possible so they can also go down the NEON pipeline. Example:
vldr.32 s0, LCPI0_0
loop:
vorr d1, d0, d0
loop2:
...
vadd.f32 d1, d1, d16
The vorr instruction looked like this after regalloc:
%S2<def> = COPY %S0, %D1<imp-def>
Copies involving odd S-registers, and copies that don't define the full
D-register are left alone.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137182 91177308-0d34-0410-b5e6-96231b3b80d8
Frontends(eg. clang) might pass incomplete form of IR, to step off the way beyond iterator end. In the case I had met, it took infinite loop due to meeting bogus PHInode.
Thanks to Jay Foad and John McCall.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137175 91177308-0d34-0410-b5e6-96231b3b80d8
Assigned symbol addresses get truncated to 32-bits, even on 64-bit platforms.
That's obviously bogus.
For example,
.globl _foo
.equ _foo, 0x987654321ULL
rdar://9922863
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137158 91177308-0d34-0410-b5e6-96231b3b80d8
This new disassembler can correctly decode all the testcases that the old one did, though
some "expected failure" testcases are XFAIL'd for now because it is not (yet) as strict in
operand checking as the old one was.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137144 91177308-0d34-0410-b5e6-96231b3b80d8
Coalescing can remove copy-like instructions with sub-register operands
that constrained the register class. Examples are:
x86: GR32_ABCD:sub_8bit_hi -> GR32
arm: DPR_VFP2:ssub0 -> DPR
Recompute the register class of any virtual registers that are used by
less instructions after coalescing.
This affects code generation for the Cortex-A8 where we use NEON
instructions for f32 operations, c.f. fp_convert.ll:
vadd.f32 d16, d1, d0
vcvt.s32.f32 d0, d16
The register allocator is now free to use d16 for the temporary, and
that comes first in the allocation order because it doesn't interfere
with any s-registers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137133 91177308-0d34-0410-b5e6-96231b3b80d8
This function doesn't have anything to do with spill weights, and MRI
already has functions for manipulating the register class of a virtual
register.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137123 91177308-0d34-0410-b5e6-96231b3b80d8
When this variable is set, "uname -r" will return its value instead of the
real OS version. Make this affect LLVM's triple for consistency.
<rdar://problem/9919167>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137111 91177308-0d34-0410-b5e6-96231b3b80d8
The 'unwind' instruction was acting essentially as a placeholder, because it
would be replaced at the end of this function by a branch to the "unwind
handler". The 'unwind' instruction is going away, so use 'unreachable' instead,
which serves the same purpose as a placeholder.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137098 91177308-0d34-0410-b5e6-96231b3b80d8
Allow labels for load/store instructions when parsing. There's encoding
issues, still, so this doesn't work all the way through, yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137064 91177308-0d34-0410-b5e6-96231b3b80d8
These the methods are target-independent since they simply scan the
memory operands. They can live in TargetInstrInfoImpl.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137063 91177308-0d34-0410-b5e6-96231b3b80d8
X86FloatingPoint keeps track of pending ST registers for an upcoming
inline asm instruction with fixed stack register constraints. It does
this by remembering which FP register holds the value that should appear
at a fixed stack position for the inline asm.
When that FP register is killed before the inline asm, make sure to
duplicate it to a scratch register, so the ST register still has a live
FP reference.
This could happen when the same FP register was copied to two ST
registers, or when a spill instruction is inserted between the ST copy
and the inline asm.
This fixes PR10602.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137050 91177308-0d34-0410-b5e6-96231b3b80d8
recurrence, the initial values low bits can sometimes be ignored.
To take advantage of this, added FoldIVUser to IndVarSimplify to fold
an IV operand into a udiv/lshr if the operator doesn't affect the
result.
-indvars -disable-iv-rewrite now transforms
i = phi i4
i1 = i0 + 1
idx = i1 >> (2 or more)
i4 = i + 4
into
i = phi i4
idx = i0 >> ...
i4 = i + 4
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137013 91177308-0d34-0410-b5e6-96231b3b80d8
All new local ranges are marked as RS_New now, so there is no need to
attempt splitting of RS_Spill ranges any more.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137002 91177308-0d34-0410-b5e6-96231b3b80d8
The local ranges created get to stay in the RS_New stage, just like for
local and region splitting.
This gives tryLocalSplit a bit more freedom the first time it sees one
of these new local ranges.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@137001 91177308-0d34-0410-b5e6-96231b3b80d8
These functions are no longer used, and they are easily replaced with a
loop calling shouldSplitSingleBlock and splitSingleBlock.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136993 91177308-0d34-0410-b5e6-96231b3b80d8
Drop the use of SplitAnalysis::getMultiUseBlocks, there is no need to go
through a SmallPtrSet any more.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136992 91177308-0d34-0410-b5e6-96231b3b80d8
Normally, we don't create a live range for a single instruction in a
basic block, the spiller does that anyway. However, when splitting a
live range that belongs to a proper register sub-class, inserting these
extra COPY instructions completely remove the constraints from the
remainder interval, and it may be allocated from the larger super-class.
The spiller will mop up these small live ranges if we end up spilling
anyway. It calls them snippets.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136989 91177308-0d34-0410-b5e6-96231b3b80d8
More parsing support for indexed loads. Fix pre-indexed with writeback
parsing for register offsets and handle basic post-indexed offsets.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136982 91177308-0d34-0410-b5e6-96231b3b80d8
Some instructions require restricted register classes, but most of the
time that doesn't affect register allocation. For example, some
instructions don't work with the stack pointer, but that is a reserved
register anyway.
Sometimes it matters, GR32_ABCD only has 4 allocatable registers. For
such a proper sub-class, the register allocator should try to enable
register class inflation since that makes more registers available for
allocation.
Make sure only legal super-classes are considered. For example, tGPR is
not a proper sub-class in Thumb mode, but in ARM mode it is.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136981 91177308-0d34-0410-b5e6-96231b3b80d8
Refactor STR[B] pre and post indexed instructions to use addressing modes for
memory operands, which is necessary for assembly parsing and is more consistent
with the rest of the memory instruction definitions. Make some incremental
progress on refactoring away the mega-operand addrmode2 along the way, which
is nice.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136978 91177308-0d34-0410-b5e6-96231b3b80d8
The old code would look at kills and defs in one pass over the
instruction operands, causing problems with this code:
%R0<def>, %CPSR<def,dead> = tLSLri %R5<kill>, 2, pred:14, pred:%noreg
%R0<def>, %CPSR<def,dead> = tADDrr %R4<kill>, %R0<kill>, pred:14, %pred:%noreg
The last instruction kills and redefines %R0, so it is still live after
the instruction.
This caused a register scavenger crash when compiling 483.xalancbmk for
armv6. I am not including a test case because it requires too much bad
luck to expose this old bug.
First you need to convince the register allocator to use %R0 twice on
the tADDrr instruction, then you have to convince BranchFolding to do
something that causes it to run the register scavenger on he bad block.
<rdar://problem/9898200>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136973 91177308-0d34-0410-b5e6-96231b3b80d8
The immediate portion of the operand is just a boolean (the 'U' bit indicating
add vs. subtract). Treat it as such.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136969 91177308-0d34-0410-b5e6-96231b3b80d8
inlined variable, based on the discussion in PR10542.
This explodes the runtime of several passes down the pipeline due to
a large number of "copies" remaining live across a large function. This
only shows up with both debug and opt, but when it does it creates
a many-minute compile when self-hosting LLVM+Clang. There are several
other cases that show these types of regressions.
All of this is tracked in PR10542, and progress is being made on fixing
the issue. Once its addressed, the re-instated, but until then this
restores the performance for self-hosting and other opt+debug builds.
Devang, let me know if this causes any trouble, or impedes fixing it in
any way, and thanks for working on this!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136953 91177308-0d34-0410-b5e6-96231b3b80d8
Enhance support for LDR instruction assembly parsing for post-indexed
addressing with immediate values. Add tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136940 91177308-0d34-0410-b5e6-96231b3b80d8
This is meant to be overriden by backends. Implement an override on PowerPC
which adjusts the offset by 2 for ha16/lo16 relocation kinds. This removes
a commented out hack and enables hello world to be compiled on PowerPC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136905 91177308-0d34-0410-b5e6-96231b3b80d8
Memory operand parsing is a bit haphazzard at the moment, in no small part
due to the even more haphazzard representations of memory operands in the .td
files. Start cleaning that all up, at least a bit.
The addressing modes in the .td files will be being simplified to not be
so monolithic, especially with regards to immediate vs. register offsets
and post-indexed addressing. addrmode3 is on its way with this patch, for
example.
This patch is foundational to enable going back to smaller incremental patches
for the individual memory referencing instructions themselves. It does just
enough to get the basics in place and handle the "make check" regression tests
we already have.
Follow-up work will be fleshing out the details and adding more robust test
cases for the individual instructions, starting with ARM mode and moving from
there into Thumb and Thumb2.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@136845 91177308-0d34-0410-b5e6-96231b3b80d8
