[PATCH] D139817: [AMDGPU] Legalize soffset of buffer instruction

[Jay Foad via Phabricator via llvm-commits]

foad added inline comments.


================
Comment at: llvm/test/CodeGen/AMDGPU/legalize-soffset-mbuf.ll:14
+  ; CHECK-NEXT:   [[V_READFIRSTLANE_B32_:%[0-9]+]]:sgpr_32 = V_READFIRSTLANE_B32 [[COPY]], implicit $exec
+  ; CHECK-NEXT:   [[BUFFER_LOAD_DWORD_OFFEN:%[0-9]+]]:vgpr_32 = BUFFER_LOAD_DWORD_OFFEN [[COPY1]], killed [[DEF]], [[V_READFIRSTLANE_B32_]], 0, 0, 0, implicit $exec :: (dereferenceable load (s32), align 1, addrspace 7)
+  ; CHECK-NEXT:   $vgpr0 = COPY [[BUFFER_LOAD_DWORD_OFFEN]]
----------------
arsenm wrote:
> foad wrote:
> > arsenm wrote:
> > > foad wrote:
> > > > arsenm wrote:
> > > > > I still think this is just a flat out wrong lowering that needs to use a waterfall loop
> > > > What's the use case for that? My understanding is that isel will never put a divergent value in soffset, and for the intrinsics we can define that soffset has to be uniform.
> > > You cannot define that a value has to be uniform. Every transform would need to be aware of that concept and apply it. load constant 32-bit is similarly broken in pretending to provide a uniformity guarantee
> > Hmm. I guess you could define that an input had to be uniform if you marked the intrinsic as the-opposite-of-convergent, to say it cannot be hoisted out of an "if"?
> I don't think we would want to do that. I think we just need to be able to handle waterfall loops for anything and have optimizations to avoid this kind of problem. We don't need a hard constraint
OK, well I have no objections to someone working on that approach. But it does feel like the optimization that you would need to implement to avoid hurting performance by introducing a waterfall loop where you don't really need one, would be very very similar to the hard constraint imposed by marking the intrinsic as the-opposite-of-convergent.


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

https://reviews.llvm.org/D139817