[clang] [CUDA][HIP] Support CUID in new driver (PR #122859)

[Joseph Huber via cfe-commits]

jhuber6 wrote:

> > > > I thought the new driver just got some entropy from the current source file's `inode` entry? I'm not opposed, since I guess it would make sense to give the user a way to override it.
> > > 
> > > 
> > > Sorry I did not quite get your question. Do you suggest that we need some option to override the CUID behavior? Currently clang already has options to disable it or set it to a fixed value.
> > 
> > 
> > I just mean that we do 'handle' static variables currently in the new driver without `CUID`, it just makes a random string based off the file's `inode` value. The CUID would then be relevant here if the user needed to override that for some reason. (Maybe some utterly bizarre parallel compilation on a remote server or compiling the same file twice with a different macro set?)
> 
> Some HIP apps (e.g. rccl) compiles the same file with different options to generate different object files. inode itself is not sufficient to identify a TU. A combination of file ID with compile options is needed to identify a TU. For CUDA/HIP, currently static device var needs to be externalized with a postfix of CUID to be able to be accessed in host code. This mechanism requires CUID to be set.
> 
> I would suggest we use the same mechanism to support static device variable in the old and new driver.

Yeah, that's fine, but we should just default to the inode method if the argument isn't present I think. That way it works without needing this extra argument passed to both the compile phases.

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