[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.
Loading
Please register or sign in to comment