Meinersbur wrote:
```
flang -fc1 host x86_64 --> modfile.mod -->
lib/clang/23/finclude/flang/x86_64-linux-gnu/iso_fortran_env.mod
/ / \ \
flang -fc1 -foffload-device nvptx / \
lib/clang/23/finclude/flang/nvptx64-nvidia-cuda/iso_fortran_env.mod
/ \
flang -fc1 -foffload-device amdgcn
lib/clang/23/finclude/flang/amdgcn-amd-amdhsa/iso_fortran_env.mod
```
The problem is that there is only one place for the modfile.mod, which is where
`-module-dir` points to. Each invocation of `-fc1` in case of offloading will
go through this file, even when the builtin modules are different. The split of
the device/host parts occurs at MLIR-level, after the AST that the .mod file is
created from, so the content of modfile.mod should be the same. Except that the
modfile.f90 remembers the checksom of the builtin modules are used at time of
creation which is what this PR fixes.
But eventually we actually may need different modules even for user-created
modules. This is because e.g. OpenMP allows definitions specific to a
particular device, i.e. `!$omp declare target` and even differentiate between
nvptx/amdgcn. Currently it seems just everything is emitted, causing issues:
#195188 #195468.
How we resolve this if we really needs different modules even for user modules
can be discussed separately. Options are to also emit it in a subdirectory of
`-module-dir`, i.e. `amdgcn-amd-amdhsa/modfile.mod`, or with another file
extention, i.e. `modfile.amdgcn-amd-amdhsa.mod`. Unfortunately build systems do
not expect additional files to appear other than the single modfile.mod. And
alternative is to put all variants into a single bundle, like
`llvm-offload-binary` puts all offload variants as fat binary with ELF
sections. We are in control of the .mod format, so we can just define
multi-sections within it.
https://github.com/llvm/llvm-project/pull/200863
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
