skatrak wrote: I'm not very knowledgeable on the set of offloading-related options clang supports, how those impact the set of invocations and options produced by the driver, or how these options eventually impact passes and codegen. Much less about potential shortcomings and improvements to the current approach, which appears to be what the discussion here is moving to. However, I can give a brief overview of what this PR stack is about.
The flang-new driver is very much based on clang, only limited in the set of options it can currently handle and adding Fortran-specific ones. In terms of offloading, it also produces a separate compiler invocation for the host and the target device, based on the same machinery and driver options as far as I can tell. One current limitation we have noticed is that the host compilation for Flang will generate offloading calls (`__tgt_target_kernel`) even when no offloading targets were specified (e.g. `--offload-arch` or `-fopenmp-targets`), resulting in linker errors: #100209. Looking into replicating what clang does to avoid this problem, I noticed that the `-fopenmp-targets` option was passed to host compiler invocations, so that it would know which offload targets are associated with it. When this is not passed, then it knows not to generate offloading calls and run directly in the host instead. This PR makes sure that it is also the case for flang-new that the `-fopenmp-targets` option is added by the driver to host offloading invocations and that `flang-new -fc1` won't complain when it gets that option. Other PRs in the stack then take this information, store it in the MLIR module and take it into consideration while generating LLVM IR for OpenMP target regions. In my opinion, the decision to potentially rename or move to a different set of offloading flags should be independent from this work, as it doesn't really add anything new, it only replicates one of the features clang already has. If a change to that is agreed upon, we can then update both clang and flang separately. If people agree, I can merge these changes and perhaps the more general discussion could be continued in discourse. https://github.com/llvm/llvm-project/pull/100152 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
