[CIR][HIP] Use CUDA attributes for HIP global functions

[koparasy]

No description provided.

[AdUhTkJm]

I'm not sure about HIP, but see this commit in upstream OG. It does some changes specific to HIP there.
Quoting from the link,

So, to summarize how the patch changes the under-the-hood kernel launch machinery:
device-side is unchanged. Kernel function is generated with the real kernel name
host-side stub is still generated with the __device_stub prefix.
host-side generates a 'handle' variable with the kernel function name, which is a pointer to the stub.
host-side registers the handle variable -> device-side kernel name association with the HIP runtime.
the address of the handle variable is used everywhere where we need a kernel pointer on the host side. I.e. passing kernel pointers around, referring to kernels across TUs, etc.
<<<>>> becomes an indirect call to a __device_stub function using the pointer retrieved from the handle.

So you might need to generate a 'handle' variable. It's different from CUDA since for CUDA the handle is just the device stub. Whether you attach the attribute to handle or the device stub depends on how HIP works - I don't quite know about it.

The attribute is used in CUDA to register the correspondence between host and device; the same kernel is mangled differently in host and device, so we need some runtime registration to map host names to device names. This registration function is going to be emitted in LLVM lowering (not written yet).

[koparasy]

I was planning on doing this redirection when I actually generate the stub function (the respective #1332) .

[AdUhTkJm]

I was planning on doing this redirection when I actually generate the stub function (the respective #1332) .

That makes sense.
Now both CUDA and HIP places the attribute on the real device stub, so hopefully we can continue to reuse lots of code.

[koparasy]

@bcardosolopes what do you think? Should I introduce a new attribute or re-use the cuda one and handle it during the generation of the device stub?

[bcardosolopes]

Incremental is fine!

what do you think? Should I introduce a new attribute or re-use the cuda one and handle it during the generation of the device stub?

We should reuse if it there isn't much difference (in which case maybe rename CUDAKernelNameAttr to GPUKernelNameAttr or something more generic, and maybe rename the file to CIRGPUAttrs.td, and CUDA support will reintroduce the attr file (and HIP get a new one) once specific ones show up. (cc @AdUhTkJm).

[AdUhTkJm]

Note this PR invalidates test CUDA/simple.cu, but it would be fixed in #1341. No idea why this passes CI though.
@bcardosolopes Will any action be taken on this? I guess it could be reverted as 1341 covers all of this PR.