[llvm] [RegisterPressure] NFC: Clean up RP handling for instructions with overlapping Def/Use (PR #109875)

Jeffrey Byrnes via llvm-commits llvm-commits at lists.llvm.org
Thu Sep 26 09:33:46 PDT 2024


jrbyrnes wrote:

> This suggests that it is not NFC? 

Well, yes and no. With the way things currently are, this change has no impact as the versions of the code are logically equivalent. This is because the generic trackers do not track by subreg. 

Since the RP tracker tracks by whole reg, if (when increasing RP) any lane in the register was previously live, then we do not modify RP (even if Width - 1 Lanes just become live). Thus, if the PreviousMask had any live lanes, we exit from increaseRegPressure since the whole reg is already live. Due to this exit, the code versions are logically equivalent (as @qcolombet confirmed)

> This cleans things up a bit and more accurately models subreg lane liveness

However, if we were to track RP by subreg (instead of whole reg), we would be interested in looking at the delta between the previous mask and the new mask in terms of individual lanes. This implies that PrevMask would model the state of live lanes before the instruction, and NewMask would model the state of live lanes after the instruction.

The current call to `increaseRegPressure(Reg, LiveAfter, ~LiveAfter & LiveBefore)` would then be incorrect. The PrevMask (LiveAfter) and NewMask (~LiveAfter & LiveBefore) are inconsistent (no lane overlap) and don't accurately model the delta for the use lanes. In particular, the NewMask (~LiveAfter & LiveBefore) doesn't accurately model the live lanes "after" the instruction from a bottomup perspective. The NewMask in the Uses loop (LiveBefore) captures this property much more accurately. 

Thus, when tracking by subreg, there are functional changes. (e.g. we need to account for this in https://github.com/llvm/llvm-project/pull/93090 or else RP tracking is broken).

> Is there any way of testing this?

Yeah, I think it may be helpful since there are a lot of details to consider when analyzing this code. The best I can think of is a unittest which checks the masks -- I'll look into this


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


More information about the llvm-commits mailing list