[PATCH] D125904: [Cuda] Use fallback method to mangle externalized decls if no CUID given

Mon May 23 14:44:15 PDT 2022

jhuber6 added a comment.

In D125904#3532492 <https://reviews.llvm.org/D125904#3532492>, @tra wrote:

> This is a moderately serious issue. Some users care about the build reproducibility. Recompiling the same sources and getting different results will trigger all sorts of red flags that would need to be investigated in order to make sure the build is not broken.

I mean this in the context that the following will not work

  clang a.c -c -o a-0.o // Has some externalized static variable.
  clang a.c -c -o a-1.o
  clang a-0.o a-1.o // Redefined symbol error

The build will be perfectly reproducible, the ID we append here is just `<var>__static__<file id><device id><line number>` which should be the same in a static source tree. Though it might be annoying that the line number may change on white-space changes, so we could do without the line number at the end if that's an issue.

>> However, this is a very niche use-case and is not supported by Nvidia's CUDA compiler so it likely to be good enough.
>
> The fact that NVCC didn't always generate the same output **was** an issue when we were using it for CUDA compilation.
> In general, "not supported by NVCC" is not quite applicable here, IMO. The goal here is to make clang work correctly.

I feel like linking a file with itself is pretty uncommon, but in order to support that we'd definitely need the CUID method so we can pass it to both the host and device. I'm personally fine with this and the CUID living together so if for whatever reason there's a symbol clash, the user can specify a CUID to make it go away. We also discussed the problem of non-static source trees which neither this nor the current CUID would solve. As far as I can tell, this method would work fine for like 99.99% of codes, but getting that last 0.01% would require something like generating a UUID for each compilation job, which requires intervention from the driver to set up offloading compilation properly. So I'm not sure if it's the best trade-off.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D125904/new/

https://reviews.llvm.org/D125904