[PATCH] D124387: AMDGPU: Fold out readfirstlane between vgpr to vgpr copies

Matt Arsenault via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Apr 25 13:33:08 PDT 2022


arsenm added inline comments.


================
Comment at: llvm/lib/Target/AMDGPU/SIFoldOperands.cpp:1858
+        //
+        // => %2 = COPY %0
+        //
----------------
foad wrote:
> b-sumner wrote:
> > arsenm wrote:
> > > b-sumner wrote:
> > > > foad wrote:
> > > > > This transformation only makes sense if you know that %0 is uniform. I think @nhaehnle has suggested introducing a "readanylane" pseudo and/or intrinsic for that kind of use case.
> > > > > 
> > > > > I'm not sure if there is any existing code that deliberately uses readfirstlane on a non-uniform argument, but if there is then this will break it.
> > > > We use readfirstlane to "elect" a value from the currently active lines.  The argument is likely not uniform, and breaking such code would be problematic.
> > > I thought this was wrong at first but don't see where the problem is. If you're reading the value back into a VGPR with the same exec mask at a later point, where is the difference? At the copy to VGPR, you're copying the from the same lane
> > This use of readfirstlane is broadcasting the value in the elected lane (.e. the first lane) to all other active lanes.
> In the original code, every lane gets the same value in %2. If you remove the readfirstlane, they might get different values (if %0 is non-uniform).
It's broadcast to a scalar value, but as soon as you have a vector use, it's reduced down to the active lanes again. It's only uniform for scalar uses


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D124387/new/

https://reviews.llvm.org/D124387



More information about the llvm-commits mailing list