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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
