[PATCH] D64862: AMDGPU/GlobalISel: RegBankSelect interp intrinsics

[Matt Arsenault via Phabricator via llvm-commits]

arsenm marked an inline comment as done.
arsenm added inline comments.


================
Comment at: lib/Target/AMDGPU/AMDGPURegisterBankInfo.cpp:1332
+      // Waterfall loop for m0 value, which is always the last operand.
+      executeInWaterfallLoop(MI, MRI, { MI.getNumOperands() - 1 });
+      return;
----------------
nhaehnle wrote:
> arsenm wrote:
> > nhaehnle wrote:
> > > We don't waterfall these in the non-GlobalISel path as far as I can tell? Should just use readfirstlane if necessary.
> > I think this is more of a defect in SelectionDAG because handling this correctly is hard. I’m considering adding a pseudo UniformVGPR register bank for cases where readfirstlane is OK
> The fact that a readfirstlane is generated instead of a waterfall loop is not a defect in SelectionDAG, at least not in general.
> 
> Frontend languages have builtins whose behavior is undefined when certain arguments are dynamically non-uniform. That is, programmers can use them in a context where the compiler cannot possibly prove that the value will be uniform, but the programmer implicitly guarantees that it will be at runtime. Emitting a readfirstlane for those when necessary is the correct behavior.
What about the case where optimizations introduce divergence into the value?


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

https://reviews.llvm.org/D64862