[llvm] [NVPTX] Improve copy avoidance during lowering. (PR #106423)

[Artem Belevich via llvm-commits]

================
@@ -269,24 +293,44 @@ static void convertToParamAS(Use *OldUse, Value *Param, bool GridConstant) {
                              OriginalUser->getIterator());
         return CvtToGenCall;
       };
-
-      if (auto *CI = dyn_cast<CallInst>(I.OldInstruction)) {
-        I.OldUse->set(GetParamAddrCastToGeneric(I.NewParam, CI));
-        return CI;
+      auto *ParamInGenericAS =
+          GetParamAddrCastToGeneric(I.NewParam, I.OldInstruction);
+
+      // phi/select could use generic arg pointers w/o __grid_constant__
----------------
Artem-B wrote:

> Ideally, we can also avoid cvta.param at Phi/Select uses if Phi/Select's all incoming values have the same address space.

We can't currently do that because when we process one argument, we do not know which decision we'll make for any other argument and that would determine what AS their pointer will end up in. We'll need to process arguments together and make sure that relevant arguments are lowered the same way. That in turn would require us to figure out which lowering combination would be the best, because different conditionals may present different requirements. E.g. if one `select` picks between an argument A and a generic pointer, and another `select` picks between the arguments A and B. If we see the second `select`, it would obviously be great to access both arguments directly, but then we get to the first select, and it must use a generic pointer and needs `cvta.param`. I guess we could insert `cvta.param` just for select's own use, but that would bring other questions -- how much overhead would such conversion bring if it's done frequently and at which point would it be beneficial just do the conversion once and always operate on generic pointers.

At the moment, I have no idea how expensive `cvta.param` is and whether there's any performance difference for loads done via generic pointer vs `ld.param`.


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