so that it will continue to test what it was meant to test when I commit a
separate change for better support of BUILD_VECTOR and VECTOR_SHUFFLE for Neon.
Fix a DAG combiner crash exposed by this test change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104380 91177308-0d34-0410-b5e6-96231b3b80d8
that are aliases of the specified register.
- Rename modifiesRegister to definesRegister since it's looking a def of the
specific register or one of its super-registers. It's not looking for def of a
sub-register or alias that could change the specified register.
- Added modifiesRegister to look for defs of aliases.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104377 91177308-0d34-0410-b5e6-96231b3b80d8
reads or writes a register.
This takes partial redefines and undef uses into account.
Don't actually use it yet. That caused miscompiles.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104372 91177308-0d34-0410-b5e6-96231b3b80d8
definitions of the virtual register.
This happens when spilling the registers produced by REG_SEQUENCE:
%reg1047:5<def>, %reg1047:6<def>, %reg1047:7<def> = VLD3d8 %reg1033, 0, pred:14, pred:%reg0
The rewriter would spill the register multiple times, dead store elimination
tried to keep up, but ended up cutting the branch it was sitting on.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104321 91177308-0d34-0410-b5e6-96231b3b80d8
<imp-def> operand for the full register. This ensures that the full physical
register is marked live after register allocation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104320 91177308-0d34-0410-b5e6-96231b3b80d8
pipeline stall. It's useful for targets like ARM cortex-a8. NEON has a lot
of long latency instructions so a strict register pressure reduction
scheduler does not work well.
Early experiments show this speeds up some NEON loops by over 30%.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104216 91177308-0d34-0410-b5e6-96231b3b80d8
test/Codegen/ARM/reg_sequence.ll but it doesn't affect the generated code
because the coalescer cleans it up. Radar 7998853.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104185 91177308-0d34-0410-b5e6-96231b3b80d8
A partial redef now triggers a reload if required. Also don't add
<imp-def,dead> operands for physical superregisters.
Kill flags are still treated as full register kills, and <imp-use,kill> operands
are added for physical superregisters as before.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104167 91177308-0d34-0410-b5e6-96231b3b80d8
partial redefines.
We are going to treat a partial redefine of a virtual register as a
read-modify-write:
%reg1024:6 = OP
Unless the register is fully clobbered:
%reg1024:6 = OP, %reg1024<imp-def>
MachineInstr::readsVirtualRegister() knows the difference. The first case is a
read, the second isn't.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104149 91177308-0d34-0410-b5e6-96231b3b80d8
lowering REG_SEQUENCE instructions.
Insert copies for REG_SEQUENCE sources not killed to avoid breaking later passes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104146 91177308-0d34-0410-b5e6-96231b3b80d8
need to be promoted. The BUILD_VECTOR and EXTRACT_VECTOR_ELT nodes generated
here already allow the promoted type to be used without further changes, so
just do the promotion. This fixes part of pr7167.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104141 91177308-0d34-0410-b5e6-96231b3b80d8
The trouble arises when the result of a vector cmp + sext is then and'ed with all ones. Instcombine will turn it into a vector cmp + zext, dag combiner will miss turning it into a vsetcc and hell breaks loose after that.
Teach dag combine to turn a vector cpm + zest into a vsetcc + and 1. This fixes rdar://7923010.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@104094 91177308-0d34-0410-b5e6-96231b3b80d8
- Change the logic DisableFramePointerElim() to check for the
-disable-non-leaf-fp-elim before -disable-fp-elim.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103990 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes the miscompilations of MultiSource/Applications/JM/l{en,de}cod.
Clang now successfully self hosts in a debug build with the fast register allocator.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103975 91177308-0d34-0410-b5e6-96231b3b80d8
While that approach works wonders for register pressure, it tends to break
everything.
This should unbreak the arm-linux builder and fix a number of miscompilations.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103946 91177308-0d34-0410-b5e6-96231b3b80d8
out aliases when allocating. Clean up allocVirtReg().
Use calcSpillCost() to allow more aggressive hinting. Now the hint is always
taken unless blocked by a reserved register. This leads to more coalescing,
lower register pressure, and less spilling.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103939 91177308-0d34-0410-b5e6-96231b3b80d8
This is safe to do because the physreg has been marked UsedInInstr and the kill flag will be set on the last operand using the virtreg if there are more then one.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103933 91177308-0d34-0410-b5e6-96231b3b80d8
Debug code doesn't use callee saved registers anyway, and the code is simpler this way. Now spillVirtReg always kills, and the isKill parameter is not needed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103927 91177308-0d34-0410-b5e6-96231b3b80d8
The implementation in LegalizeIntegerTypes to handle this as
sint64->float + appropriate power of 2 is subject to double rounding,
considered incorrect by numerics people. Use this implementation only
when it is safe. This leads to using library calls in some cases
that produced inline code before, but it's correct now.
(EVTToAPFloatSemantics belongs somewhere else, any suggestions?)
Add a correctly rounding (though not particularly fast) conversion
that uses X87 80-bit computations for x86-32.
7885399, 5901940. This shows up in gcc.c-torture/execute/ieee/rbug.c
in the gcc testsuite on some platforms.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103883 91177308-0d34-0410-b5e6-96231b3b80d8
a condition's grouping. Every other use of Allocatable.test(Hint) groups it the
same way as it is indented, so move the parentheses to agree with that
grouping.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103869 91177308-0d34-0410-b5e6-96231b3b80d8
When working top-down in a basic block, substituting physregs for virtregs, the use-def chains are kept up to date. That means we can recognize a virtreg kill by the use-def chain becoming empty.
This makes the fast allocator independent of incoming kill flags.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103866 91177308-0d34-0410-b5e6-96231b3b80d8
instructions.
e.g.
%reg1026<def> = VLDMQ %reg1025<kill>, 260, pred:14, pred:%reg0
%reg1027<def> = EXTRACT_SUBREG %reg1026, 6
%reg1028<def> = EXTRACT_SUBREG %reg1026<kill>, 5
...
%reg1029<def> = REG_SEQUENCE %reg1028<kill>, 5, %reg1027<kill>, 6, %reg1028, 7, %reg1027, 8, %reg1028, 9, %reg1027, 10, %reg1030<kill>, 11, %reg1032<kill>, 12
After REG_SEQUENCE is eliminated, we are left with:
%reg1026<def> = VLDMQ %reg1025<kill>, 260, pred:14, pred:%reg0
%reg1029:6<def> = EXTRACT_SUBREG %reg1026, 6
%reg1029:5<def> = EXTRACT_SUBREG %reg1026<kill>, 5
The regular coalescer will not be able to coalesce reg1026 and reg1029 because it doesn't
know how to combine sub-register indices 5 and 6. Now 2-address pass will consult the
target whether sub-registers 5 and 6 of reg1026 can be combined to into a larger
sub-register (or combined to be reg1026 itself as is the case here). If it is possible,
it will be able to replace references of reg1026 with reg1029 + the larger sub-register
index.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103835 91177308-0d34-0410-b5e6-96231b3b80d8
the variable actually tracks.
N.B., several back-ends are using "HasCalls" as being synonymous for something
that adjusts the stack. This isn't 100% correct and should be looked into.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103802 91177308-0d34-0410-b5e6-96231b3b80d8
- Kill is implicit when use and def registers are identical.
- Only virtual registers can differ.
Add a -verify-fast-regalloc to run the verifier before the fast allocator.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103797 91177308-0d34-0410-b5e6-96231b3b80d8
-filetype=obj test, and -filetype=obj leaks a few objects. Added a FIXME, we
need to sort out the ownership model for the various MC objects.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103769 91177308-0d34-0410-b5e6-96231b3b80d8
This loop is quadratic in the capacity for a DenseMap:
while(!map.empty())
map.erase(map.begin());
Instead we now do a normal begin() - end() iteration followed by map.clear().
That also has the nice sideeffect of shrinking the map capacity on demand.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103747 91177308-0d34-0410-b5e6-96231b3b80d8
Now, the .linkonce directive is emitted as part of MCSectionCOFF::PrintSwitchToSection instead of AsmPrinter::EmitLinkage since it is an attribute of the section the symbol was placed into not the symbol itself.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103568 91177308-0d34-0410-b5e6-96231b3b80d8
This allows us to add accurate kill markers, something the scavenger likes.
Add some more tests from ARM that needed this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103521 91177308-0d34-0410-b5e6-96231b3b80d8
create separate virtual registers for CopyFromReg values, so uses of
them don't necessarily kill the value.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103519 91177308-0d34-0410-b5e6-96231b3b80d8
to LLVM_LIBRARY_VISIBILITY and introduce LLVM_GLOBAL_VISIBILITY, which is
the opposite, for future use by dragonegg.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103495 91177308-0d34-0410-b5e6-96231b3b80d8
Sorry for the big change. The path leading up to this patch had some TableGen
changes that I didn't want to commit before I knew they were useful. They
weren't, and this version does not need them.
The fast register allocator now does no liveness calculations. Instead it relies
on kill flags provided by isel. (Currently those kill flags are also ignored due
to isel bugs). The allocation algorithm is supposed to work with any subset of
valid kill flags. More kill flags simply means fewer spills inserted.
Registers are allocated from a working set that contains no aliases. That means
most allocations can be done directly without expensive alias checks. When the
working set runs out of registers we do the full alias check to find new free
registers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103488 91177308-0d34-0410-b5e6-96231b3b80d8
Move EmitTargetCodeForMemcpy, EmitTargetCodeForMemset, and
EmitTargetCodeForMemmove out of TargetLowering and into
SelectionDAGInfo to exercise this.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103481 91177308-0d34-0410-b5e6-96231b3b80d8
SSAUpdater for the value from the first def may see uses of undefined values,
because the later defs will not have been updated yet.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103407 91177308-0d34-0410-b5e6-96231b3b80d8
getConstantFP to accept the two supported long double
target types. This was not the original intent, but
there are other places that assume this works and it's
easy enough to do.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103299 91177308-0d34-0410-b5e6-96231b3b80d8
with the fix in 103157.
%reg1039:1<def> = VMOVS %S1<kill>, pred:14, pred:%reg0
is not coalescable since none of the super-registers of S1 are in reg1039's
register class: DPR_VFP2. But it is still a legal copy instruction so it should
not assert.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103170 91177308-0d34-0410-b5e6-96231b3b80d8
Users can write broken code that emits the same label twice with asm renaming,
detect this and emit a fatal backend error instead of aborting.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103140 91177308-0d34-0410-b5e6-96231b3b80d8
of just letting them inherit the debug locations of adjacent instructions.
Debug info should aim to be either accurate or absent.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@103135 91177308-0d34-0410-b5e6-96231b3b80d8
in registers into a separate function to de-couple it from the
top-down-specific logic in getRegForValue.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102975 91177308-0d34-0410-b5e6-96231b3b80d8
debug output is showing machine instructions, the IR-level basic block names
aren't very meaningful, and because multiple machine basic blocks may be
derived from one IR-level BB, they're also not unique.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102960 91177308-0d34-0410-b5e6-96231b3b80d8
beneficial cases. See the changes in test/CodeGen/X86/tail-opts.ll and
test/CodeGen/ARM/ifcvt2.ll for details.
The fix is to change HashEndOfMBB to hash at most one instruction,
instead of trying to apply heuristics about when it will be profitable to
consider more than one instruction. The regular tail-merging heuristics
are already prepared to handle the same cases, and they're more precise.
Also, make test/CodeGen/ARM/ifcvt5.ll and
test/CodeGen/Thumb2/thumb2-branch.ll slightly more complex so that they
continue to test what they're intended to test.
And, this eliminates the problem in
test/CodeGen/Thumb2/2009-10-15-ITBlockBranch.ll, the testcase from
PR5204. Update it accordingly.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102907 91177308-0d34-0410-b5e6-96231b3b80d8
preventing the emission of the NOP on Darwin for a
function with no actual code. From timberwolfmc
with TEST=optllcdbg.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102843 91177308-0d34-0410-b5e6-96231b3b80d8
code, and to eliminate the need for the SelectionDAGBuilder
state to be live during CodeGenAndEmitDAG calls.
Call SDB->clear() before CodeGenAndEmitDAG calls instead of
before it, and move the CurDAG->clear() out of SelectionDAGBuilder,
which doesn't own the DAG, and into CodeGenAndEmitDAG.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102814 91177308-0d34-0410-b5e6-96231b3b80d8
indexes could be of a different value type. Or not even using the same SDNode
for the constant (weird, I know). Compare the actual values instead of the
pointers.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102791 91177308-0d34-0410-b5e6-96231b3b80d8
instruction selection is done; it's confusing to see parts of it printed,
while other parts are omitted, along the way.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102771 91177308-0d34-0410-b5e6-96231b3b80d8
call that might throw. The landing pad assumes that all registers are in stack
slots.
We used to spill those dirty CSRs after the call, and the stack slots would be
wrong when arriving at the landing pad.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102770 91177308-0d34-0410-b5e6-96231b3b80d8
of different register classes. e.g.
%reg1048:3<def> = EXTRACT_SUBREG %RAX<kill>, 3
Where %reg1048 is a GR32 register. This is not impossible to handle, but it is
pretty hard and very rare.
This should unbreak the dragonegg builder.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@102672 91177308-0d34-0410-b5e6-96231b3b80d8
