yaxunl added a comment. In D125904#3537952 <https://reviews.llvm.org/D125904#3537952>, @tra wrote:
> How much work would it take to add cuid generation in the new driver, similar > to what the old driver does, using the same logic, however imperfect it is? > I'd be OK with that as a possibly permanent solution. > > I'm somewhat wary of temporary solutions as they tend to become permanent and > age poorly. > That said, I'm OK with someone else tie-breaking us here. > @yaxunl -- Sam, do you have an opinion? I am OK with this patch. I doubt it is possible to find a solution for static variable without some form of CUID. Assuming we can rename duplicate symbols in device linker. We still need to let the host compiler know which symbol is for which TU+option, then we still need some CUID to match device and host compilation. That said, this patch provided a default CUID that do not depend on driver, which is its advantage. It should be OK for most usecases. Driver provided CUID has more robustness, so it can serve as last resort. If the fallback is not sufficient for the new driver then we can revisit this. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D125904/new/ https://reviews.llvm.org/D125904 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
