yxsamliu 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. 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
