tra added inline comments.
================ Comment at: llvm/lib/Target/NVPTX/NVPTXCtorDtorLowering.cpp:58 + ((IsCtor ? "__init_array_object_" : "__fini_array_object_") + + F->getName() + "_" + getHash(M.getName()) + "_" + + std::to_string(Priority)) ---------------- jhuber6 wrote: > tra wrote: > > Source file name may be a little bit better, though it's still easy to > > clash if someone does `cd A; clang ./foo.c; cd ../B; clang ./foo.c` and the > > file name uses relative paths. > > > > I think we'll need a way to override this unique suffix explicitly as an > > escape hatch for cases where someone runs into a clash. > I figured it'd be good enough since this is admittedly *very* niche. So > someone would need to have a file called `foo.c` that also had a constructor > called `foo` in it. For it to clash. Isn't it too late to grab the source > filename while we're in the backend lowering stage? > someone would need to have a file called foo.c that also had a constructor > called foo in it Unlikely != impossible. It's a trade-off between the hassle of implementing the plan B and the hassle of debugging and working around the clash for someone who runs into this. On one hand that's indeed unlikely to happen, but, given enough exposure, someone/somewhere will run into it and they will likely be ill-equipped to even tell what's going on. In general, compiler options are logistically much easier to deal with compared to having to change the source code. > Isn't it too late to grab the source filename while we're in the backend > lowering stage? The module already has the file name recorded and available via `llvm::Module::getSourceFileName()`, so it's as easy to get as the module name. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D149451/new/ https://reviews.llvm.org/D149451 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
