Skip to content
Commit b3f0819f authored by Roger Ferrer's avatar Roger Ferrer
Browse files

[LiveRangeEdit][RISCV] Allow rematerialization to extend live ranges

This goes against common wisdom: live ranges are not to be extended.
However, cross-bank instructions (such a vector-splat) may benefit
from being able to do that, especially in systems where spilling
one register class is more expensive than the other (in EPI spill code
for vectors is much more expensive than spill code for the scalar +
vector-splat).

This change leverages the fact that in RISC-V RA happens in two steps:
first vectors and then scalars (and insert vsetvli happens inbetween),
so some of the rematerializations for vectors are still available.

In the case of vector-splats, when they cannot be folded into the
instructions (like in the testcase) they are typically hoisted out of
the loop. This is efficient but can cause spill code (like in the testcase).
So we end with a loop that in each iteration reloads a vector that is
basically a splat. Computing a splat is much faster than loading a vector
and is also faster than having to load the scalar before the splat (if
the scalar got spilled too).

But rematerialization does not happen if the live ranges are not available
at the point of the rematerialization. And this is what happens with
hoisted vector-splats, the scalar used in the splat may not be live in the
loop body. So in this case we extend the live range of the scalar so it is
live to the rematerialization point. We do that only in a very restricted
set of cases and we have observed not a lot of disturbance to other
RISC-V testcases.

This is gated by a TargetInstrInfo hook which is only set to true in EPI.
parent e493e776
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment