jhuber6 added inline comments.
================ Comment at: clang/lib/Driver/ToolChains/Clang.cpp:8205 + if (llvm::find(LibraryArgs, "m") == LibraryArgs.end() && !D.CCCIsCXX()) + continue; + ---------------- JonChesterfield wrote: > jdoerfert wrote: > > JonChesterfield wrote: > > > 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. > > Opting out of "optional" gpu libraries is fine. I want to avoid that one > > needs to add linking flags etc. for OpenMP. We link libdevice by default > > too, so this is no different (as both contain math function impl etc.) > I guess that hangs on whether libm is optional or not. > > I am reluctant to tie every openmp execution to the rocm libdevice as it > frequently fails to build with llvm trunk and I'm nervy about linking IR > built by the rocm clang with IR generated from trunk. It mostly seems to work > for rocm sufficiently similar in age to trunk but periodically the abi or > intrinsic set diverges. > > Maybe our working assumption should be that everyone using openmp wants libm > so rocm breaking trunk openmp has to be resolved each time it happens anyway. > If so, there's a design decision to be made about how to manage that > dependency. I tested this on Spock and it resolves linking math libraries. I'm not sure about overall stability however. I'm assuming this is sufficient until we get a real libdevice for AMDGPU. 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
