[flang-commits] [clang] [flang] [Flang] Fix device-side module lookup (PR #200863)

[Michael Kruse via flang-commits]

Meinersbur wrote:

NB: #201103 adds support for DECLARE_TARGET by setting a device-type flag in the AST that can be specialized later in MLIR, i.e. still the same .mod for device and and target. Handling `!$omp declare variant` requires more effort; from the OpenMP examples document:

```f90
subroutine base_saxpy(s,x,y) !! base function
  real,intent(inout) :: s,x(:),y(:)
  !$omp declare variant( avx512_saxpy ) &
  !$omp& match( device={isa("core-avx512")} )

  y = s*x + y
end subroutine

subroutine avx512_saxpy(s,x,y) !! function variant
  ...
```

Keeping a single .mod file for all targets means that `avx512_saxp` must be kept in case it is used for a target that supports avx512. In contrast, Clang just skips anything it does match to the current compilation target in the preprocessor or while creating the AST. A rationale is that `avx512_saxpy` may contain inline-asm or vector builtins that the current compilation just does not know about and need to fail if parsed. gcc on the other hand will parse everything and diverge between host and device at a later stage, like Flang does. Thanks to the insistance by gcc implementors, OpenMP does not have predefined preprocessor symbols that are different when compiling for different targets (like [`__HIP_DEVICE_COMPILE__`](https://clang.llvm.org/docs/HIPSupport.html#predefined-macros), [`__CUDA_ARCH__`](https://docs.nvidia.com/cuda/cuda-programming-guide/05-appendices/cpp-language-extensions.html#codecell0) ,[`__SYCL_DEVICE_ONLY__`](https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#_preprocessor_directives_and_macros)) which require the split to happen at the preprocessor stage.

I don't know whether CUDA-Fortran has a `__CUDA_ARCH__` preprocessor definition or similar which could be used to compile very different sources for host and devices.

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