Fix overly pessimistic shortcut in post-RA MachineLICM
authorRichard Sandiford <rsandifo@linux.vnet.ibm.com>
Tue, 20 Aug 2013 09:11:13 +0000 (09:11 +0000)
committerRichard Sandiford <rsandifo@linux.vnet.ibm.com>
Tue, 20 Aug 2013 09:11:13 +0000 (09:11 +0000)
commit96aa93d5f18cc56915b24f07ad98b776ce616ca3
treeb2bc6532ad138b0d98f04c9012e90dd05e20e910
parentf79c3a5aefefaf7de1b4c5787871f09d947d85f1
Fix overly pessimistic shortcut in post-RA MachineLICM

Post-RA LICM keeps three sets of registers: PhysRegDefs, PhysRegClobbers
and TermRegs.  When it sees a definition of R it adds all aliases of R
to the corresponding set, so that when it needs to test for membership
it only needs to test a single register, rather than worrying about
aliases there too.  E.g. the final candidate loop just has:

    unsigned Def = Candidates[i].Def;
    if (!PhysRegClobbers.test(Def) && ...) {

to test whether register Def is multiply defined.

However, there was also a shortcut in ProcessMI to make sure we didn't
add candidates if we already knew that they would fail the final test.
This shortcut was more pessimistic than the final one because it
checked whether _any alias_ of the defined register was multiply defined.
This is too conservative for targets that define register pairs.
E.g. on z, R0 and R1 are sometimes used as a pair, so there is a
128-bit register that aliases both R0 and R1.  If a loop used
R0 and R1 independently, and the definition of R0 came first,
we would be able to hoist the R0 assignment (because that used
the final test quoted above) but not the R1 assignment (because
that meant we had two definitions of the paired R0/R1 register
and would fail the shortcut in ProcessMI).

This patch just uses the same check for the ProcessMI shortcut as
we use in the final candidate loop.

llvm-svn: 188774
llvm/lib/CodeGen/MachineLICM.cpp
llvm/test/CodeGen/SystemZ/asm-17.ll