[llvm] [SystemZ] Add a SystemZ specific pre-RA scheduling strategy. (PR #135076)
Jonas Paulsson via llvm-commits
llvm-commits at lists.llvm.org
Wed Apr 16 10:46:16 PDT 2025
JonPsson1 wrote:
> Do you have any insights on why and how the existing pressure set approach is insufficient?
That's a good question... Maybe it is doing too little too late - it waits for certain limits to be reached but then it has already opened up many register intervals and for some reason it isn't enough to try to reduce register pressure at that point. It seems to work better to reduce liveness regardless of the current pressure, that is as soon as possible.
I am not sure if the PSets themselves are overly complex and get in the way of things: On SystemZ, the simple approach I am using is to consider the fact of basically two sets of registers available: FP regs (which overlap the vector regs), and the GPR regs. The idea is to reduce FP pressure as much as possible by ignoring GPR regs in FP intensive regions. I see 5 PSets on SystemZ, but I am not sure that works the same as having just two, but ideally it should. Prioritizing FP regs seems to work well, and is maybe an important difference to the GenericScheduler.
Another difference is that it seems to work better not to consider memory operands (GPR registers used to hold addresses), as they are not naturally part of the data flow. This is something PSets don't know about - how the register is actually used. But I don't think that is a major point in all this.
I have also seen the handling of critical PSets go wrong with a large region which is very FP intensive. In the *input order*, it is the integer sets that have the most pressure, but there is a lot of potential FP overlap which results after scheduling (with increased heavy spilling). I tried fixing this however by providing the correct critical PSets, but it did not help much on that test case. Another option I haven't tried (suggested by @atrick, I think) is to have a second pass which could among other things maybe correct this if it goes wrong. This I haven't tried however.
https://github.com/llvm/llvm-project/pull/135076
More information about the llvm-commits
mailing list