JonChesterfield added a comment. I'm not confident it's only attributes that we rely on mlink-builtin-bitcode patching up, that could be poor phrasing on my part.
Making the pipeline robust to underspecified IR input may be easier (and arguably more useful) than changing the rocm library to be compiled for a given target. ================ Comment at: clang/lib/Driver/ToolChains/Clang.cpp:8205 + if (llvm::find(LibraryArgs, "m") == LibraryArgs.end() && !D.CCCIsCXX()) + continue; + ---------------- jhuber6 wrote: > jdoerfert wrote: > > I'd switch the conditions. > > > > More importantly, does this require that the user passes -lm to the linker > > invocation? I'm not convinced we should not always link these in. > Yes, would save some time assuming most codes are C++ > > So I figured I'd copy the same semantics of how `-lm` works where you need to > specify it for C but not C++. We could just pass this in all the time, but > since linking it in currently required `-lm` I copied that. re: always linking these libraries in, regardless of -lm, it's probably better to link them by default and effectively ignore -lm. I'd like to keep it guarded by -nogpulib or similar so that people can still opt out of the rocm device library stack entirely. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D119841/new/ https://reviews.llvm.org/D119841 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
