[libc-commits] [clang] [compiler-rt] [flang] [libc] [libcxx] [libcxxabi] [libunwind] [llvm] [openmp] [Flang] Move builtin .mod generation into runtimes (Reapply #137828) (PR #171515)

[Tarun Prabhu via libc-commits]

================
@@ -1179,6 +1179,37 @@ void Flang::ConstructJob(Compilation &C, const JobAction &JA,
   CmdArgs.push_back("-resource-dir");
   CmdArgs.push_back(D.ResourceDir.c_str());
 
+  // Default intrinsic module dirs must be added after any user-provided
+  // -fintrinsic-modules-path to have lower precedence
+  if (std::optional<std::string> IntrModPath =
+          TC.getDefaultIntrinsicModuleDir()) {
+    CmdArgs.push_back("-fintrinsic-modules-path");
+    CmdArgs.push_back(Args.MakeArgString(*IntrModPath));
+  }
+
+  // Ideally, every target triple has its own set of builtin modules since they
+  // are compiled with platform-dependent conditionals such as `#if __x86_64__`.
+  // However, getting the builtin modules for offload targets requires building
+  // the flang-rt and openmp for those targets as well:
+  // -DLLVM_RUNTIME_TARGETS=default;amdgcn-amd-amdhsa;nvptx64-nvidia-cuda.
+  // To reduce friction when build systems have not yet been updated, we also
+  // add the host's builtin module to the search path (with lower priority), in
+  // case a module file has not been found for the offload targets itself.
+  // FIXME: This workaround may mix module files targeting different triples and
----------------
tarunprabhu wrote:

Sorry, I still don't understand. I think my confusion stems from the use of the term "build systems" here. It is not clear if you mean other parts of LLVM's own build system, or if it means that applications _using_ flang need to adjust something.

https://github.com/llvm/llvm-project/pull/171515