Turn this:
movswl %ax, %eax
movl %eax, -36(%ebp)
xorl %edi, -36(%ebp)
into
movswl %ax, %eax
xorl %edi, %eax
movl %eax, -36(%ebp)
by unfolding the load / store xorl into an xorl and a store when we know the
value in the spill slot is available in a register. This doesn't change the
number of instructions but reduce the number of times memory is accessed.
Also unfold some load folding instructions and reuse the value when similar
situation presents itself.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@42947 91177308-0d34-0410-b5e6-96231b3b80d8
(almost) a register copy. However, it always coalesced to the register of the
RHS (the super-register). All uses of the result of a EXTRACT_SUBREG are sub-
register uses which adds subtle complications to load folding, spiller rewrite,
etc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@42899 91177308-0d34-0410-b5e6-96231b3b80d8
- If the defs of a spilled rematerializable MI are dead after the spill store is deleted, delete
the def MI as well.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@41086 91177308-0d34-0410-b5e6-96231b3b80d8
no more uses within the MBB and the spilled value isn't live out of the MBB.
Then it's safe to delete the spill store.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@41069 91177308-0d34-0410-b5e6-96231b3b80d8
with a general target hook to identify rematerializable instructions. Some
instructions are only rematerializable with specific operands, such as loads
from constant pools, while others are always rematerializable. This hook
allows both to be identified as being rematerializable with the same
mechanism.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@37644 91177308-0d34-0410-b5e6-96231b3b80d8
The code sequence before the spiller is something like:
= tMOVrr
%reg1117 = tMOVrr
%reg1078 = tLSLri %reg1117, 2
The it starts spilling:
%r0 = tRestore <fi#5>, 0
%r1 = tRestore <fi#7>, 0
%r1 = tMOVrr %r1<kill>
tSpill %r1, <fi#5>, 0
%reg1078 = tLSLri %reg1117, 2
It restores the value while processing the first tMOVrr. At this point, the
spiller remembers fi#5 is available in %r0. Next it processes the second move.
It restores the source before the move and spills the result afterwards. The
move becomes a noop and is deleted. However, a spill has been inserted and that
should invalidate reuse of %r0 for fi#5 and add reuse of %r1 for fi#5.
Therefore, %reg1117 (which is also assigned fi#5) should get %r1, not %r0.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34039 91177308-0d34-0410-b5e6-96231b3b80d8
t1 := op t2, t3
t2 <- assigned r0 for use by the reload but ended up reuse r1
t3 <- assigned r1 for use by the reload but ended up reuse r0
t1 <- desires r1
sees r1 is taken by t2, tries t2's reload register r0
sees r0 is taken by t3, tries t3's reload register r1
sees r1 is taken by t2, tries t2's reload register r0 ...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@33382 91177308-0d34-0410-b5e6-96231b3b80d8
rework the hacks that had us passing OStream in. We pass in std::ostream*
instead, check for null, and then dispatch to the correct print() method.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@32636 91177308-0d34-0410-b5e6-96231b3b80d8
If a spillslot value is available in a register, and there is a noop copy that
targets that register, the spiller correctly decide not to invalidate the
spillslot register.
However, even though the noop copy does not clobbers the value. It does start a
new intersecting live range. That means the spillslot register is available for
use but should not be reused for a two-address instruction modref operand which
would clobber the new live range.
When we remove the noop copy, update the available information by clearing the
canClobber bit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@32576 91177308-0d34-0410-b5e6-96231b3b80d8
tied to another oeprand, 2) whether is is being tied to by another operand. So
the destination operand of a two-address MI can be correctly identified.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@32354 91177308-0d34-0410-b5e6-96231b3b80d8
there may be other def(s) apart from the use&def two-address operand. We need
to check if the register reuse for a use&def operand may conflicts with another
def. Provide a mean to recover from the conflict if it is detected when the
defs are processed later.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@31439 91177308-0d34-0410-b5e6-96231b3b80d8
