Certain MVE instructions, such as the narrowing loads, can be created with frame indices even though they do not accept sp as a register. This makes sure that if we have situations like that, we have an emergency register to use as the frame base, to ensure that we do not run out of registers.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
The AddrModeT2_i7, etc can still be generated from the non-widening forms of the MVE loads/stores (as they accept a GPR not a tGPR they can take SP too). I don't think the narrowing loads (the ones that cannot accept a stack pointer) will be generated any more, but I'd prefer to fix these cases nonetheless. They may change in the future and these failures are silent until the function gets complex enough to trigger them, so can be difficult to test for.
The widening/narrowing MVE loads and stores, like MVE_VLDRBU32 (the B with the 32, in this example) can only take "thumb" registers as they only have 3 bits for the Rn operand. Which is what I meant by "can't take SP". This is not something that any other stack load/store has had to deal with in the past, and hence RegClass->contains(ARM::SP) is added here to check for such cases. Similar to https://reviews.llvm.org/D66285.
The other MVE loads/stores, like a MVE_VLDRBU8 do have the full 4 bits needed for "Thumb2" register, so do not hit the same problem. They can accept a SP and it will only be a problem for frame indices if the offset is out of range of the instruction.
I've added another test for that second case.