[llvm] [RISCV][WIP] Let RA do the CSR saves. (PR #90819)

[Quentin Colombet via llvm-commits]

qcolombet wrote:

> @qcolombet
> 
> Hi Quentin,
> 
> Thank you for the comments. After I looked into some degradations, I see that you are exactly right!
> 
> > proper way to handle them would be to issue parallel copies
> 
> Interesting, you mean we should put all the copies into one instruction bundle?

Yes, but that will not be enough because RA needs to be taught how to break the bundle if some of the copies need to be spilled.

> 
> > As you saw, this change in representation creates regression because the CSR distinction is baked left and right in the backend. So we can fix them as we find them, but there'll be a long tail.
> 
> In particular in the register allocator I see that CSRs are treated differently: since there is some cost to use CSR for the first time, there is some logic trying to minimize these costs. In this approach, I think this logic is working against us.

Not surprised and that's what I was referring to when I was saying that CSRs are treated differently left and right.

> 
> Here's another problem that I saw: when trying to allocate for the live range of `x1` (the return-address register on RISCV), the allocator thinks its a good idea to evict previously allocated CSR's live range (even if it means breaking a hint). This eventually leads to many unnecessary spills. Looks like this is exactly the situation you described here:
> 
> > Example of issue with CSR using sequential copies
> 
> v1 = COPY csr1 v2 = COPY csr2 v3 = COPY csr3 If for some reason csr3 gets used for something else, you are at the mercy of the RA ordering for the coalescing. I.e., worst case, you may end up with:
> 
> some_reg = COPY csr1 csr1 = COPY csr2 csr2 = COPY csr3 instead of
> 
> csr1 = COPY csr1 # no-op csr2 = COPY csr2 # no-op some_reg = COPY csr3
> 
> I have tried some hacks which basically disable eviction if it breaks hints and they make the problem go away, but I am not sure what the proper solution to this should be, maybe we can discuss it during your office hour.

Sadly I don't think there's a good solution here. RA's decisions are currently too narrow-scoped to reason about this kind of things. The eviction chain heuristic is supposed to help with these cases, but this is a heuristic! (Plus it may be disabled by default, I don't remember.)

Long story short, if we want to go down that path, I think that a more serious overhaul of the RA infrastructure is needed.



https://github.com/llvm/llvm-project/pull/90819