[llvm] [RISCV][WIP] Let RA do the CSR saves. (PR #90819)
Mikhail Gudim via llvm-commits
llvm-commits at lists.llvm.org
Tue Jun 25 13:53:57 PDT 2024
mgudim 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?
> 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.
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.
https://github.com/llvm/llvm-project/pull/90819
More information about the llvm-commits
mailing list