[llvm] [NVPTX] Add errors for incorrect CUDA addrpaces (PR #138706)

[Artem Belevich via llvm-commits]

================
@@ -1399,19 +1399,27 @@ void NVPTXAsmPrinter::emitFunctionParamList(const Function *F, raw_ostream &O) {
       if (PTy) {
         O << "\t.param .u" << PTySizeInBits << " .ptr";
 
+        bool IsCUDA = static_cast<NVPTXTargetMachine &>(TM).getDrvInterface() ==
+                      NVPTX::CUDA;
         switch (PTy->getAddressSpace()) {
         default:
           break;
         case ADDRESS_SPACE_GLOBAL:
           O << " .global";
           break;
         case ADDRESS_SPACE_SHARED:
+          if (IsCUDA)
+            report_fatal_error(".shared ptr kernel args unsupported in CUDA.");
           O << " .shared";
           break;
         case ADDRESS_SPACE_CONST:
+          if (IsCUDA)
+            report_fatal_error(".const ptr kernel args unsupported in CUDA.");
----------------
Artem-B wrote:

On a second thought, I'm not quite convinced that we want this change.

> The CUDA API only accepts kernel params in the global and generic address spaces, so display an error message when attempting to emit pointers outside those address-spaces from CUDA (but still allow them for OpenCL).

@LewisCrawford can you elaborate on the motivation and the use case for this change?

CUDA operates on *generic* pointers, as far as the front-end is concerned, so I'm not quite sure which CUDA APIs you have in mind here that may be affected if we generate `.ptr .const`? 

Can you give me a few examples where these errors should be triggered when we compile CUDA sources? The included tests all operate on the IR level, so I can't tell what is the problem that this patch wants to address.

On the IR level, erroring out does not make whole lot of sense to me.  If the compilation of the CUDA sources can lead to such an IR, it should be diagnosed by the front-end. If we made this far in the compilation pipeline, I do not see why we would want to error out here, attempting to generate what appears to be a perfectly valid PTX.
What can possibly go wrong here that it's LLVM's job to prevent?


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