[llvm] [AMDGPU] Add post-RA peephole to fuse v_lshlrev_b32 + v_or_b32 into v_lshl_or_b32 (PR #202585)

[Barbara Mitic via llvm-commits]

barbara-amd wrote:




> > >Existing TableGen patterns for this fusion rarely fire because they rely on conservative SelectionDAG-level analysis. The HasOneUseBinOp predicate rejects cases where the shift has multiple DAG-level uses but only one after register allocation.
> 
> >These statements sound a little bit like AI-generated overconfidence. Why would register allocation reduce the number of uses? And if was true, surely this would apply to almost every instruction selection pattern that has a one-use check.
> 
> You're right, that's wrong - RA doesn't reduce use counts. I checked the cases this fires on and the shift already has a single use at ISel, so HasOneUseBinOp isn't the blocker. I'll remove that claim.
> > > Constant-bus and
> 
> >On GFX10+ the constant bus limit allows for 2 of the 3 inputs to be SGPRs, which seems pretty generous. So does this patch give any benefit on GFX10+ or is it really only helpful for GFX9 and earlier?
> 
>Yes, it helps on GFX10+. You can see it directly in the test diffs: in fptoui-sat-vector.ll the new v_lshl_or_b32 lines land under the GFX11 and GFX12 check prefixes, for example.
>
> > >divergence checks are similarly conservative without final register classes.
> 
> >I don't understand what this means about divergence checks being conservative, except perhaps in the rare-ish case that we end up using a VGPR for a uniform value.
>
>Right. These are the test_s_* (uniform inreg) conversion functions - e.g. test_s_unsigned_v4f16_v4i8 in fptoui-sat-vector.ll. From my understanding, the values end up in VGPRs but ThreeOpFragSDAG skips them on the !isDivergent() check, so the peephole fuses them post-RA.



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