[flang-commits] [flang] [llvm] [flang] Use backend fp128 support to determine REAL(16) availability (PR #221907)

[Shunsuke Watanabe via flang-commits]

s-watanabe314 wrote:

Thanks for agreeing with the general direction. My understanding from the discussion so far is that `REAL(16)` support would be available under the following conditions. Unfortunately, I only have access to x86_64 and AArch64 systems, so I have not been able to verify builds and tests on other architectures.

- Native support:
`isTypeLegal(f128) == true && getTypeAction(ctx, f128VT) == TypeLegal && getOperationAction(ISD::FADD, f128VT) == Legal`
This appears to be true for: `s390x`, `systemz`, `ve`

- Libcall-based support:
`getLibcallName(RTLIB::ADD_F128) != nullptr`
The target knows the runtime library name corresponding to `ADD_F128` (and similarly `SUB_F128`, `MUL_F128`, and `DIV_F128`). This condition is satisfied by 131 targets, including the three targets with native support listed above.

Under these criteria, 131 of the 148 targets that I surveyed would newly gain REAL(16) support. Enabling quadruple-precision compilation for that many targets has a fairly large impact, and I am concerned because I cannot verify that Flang builds and works correctly in all cases. My main concern is how to keep the frontend and runtime decisions regarding `REAL(16)` support consistent during the runtime bootstrap build.

At the very least, I believe the regression test `flang-rt/test/Driver/compare_iso_fortran_env_symbols.f90` would fail. 
The issue comes from `__builtin_real_kinds` in `iso_fortran_env_impl.cpp`, which uses `FLANG_RT_SUPPORTS_REAL16` to determine whether `REAL(16)` should be exposed by the runtime.

iso_fortran_env_impl.cpp:
https://github.com/llvm/llvm-project/blob/585df631037b5cf8d822b9d6de5abb74cf79d1f4/flang-rt/lib/runtime/iso_fortran_env_impl.cpp#L239-L251

On the other hand, the test compares the built runtime against the module generated by Flang from `iso_fortran_env_impl.f90`. In other words, the runtime build needs to make the same `REAL(16)` availability decision as the frontend.

In the current patch, I force `REAL(16)` support on x86_64 and AArch64 in CMake:
```CMake
# Determine whether REAL(16) intrinsic modules should be built for the target.
function(check_real16_support target result)
  if(FLANG_RUNTIME_F128_MATH_LIB
      OR HAVE_LDBL_MANT_DIG_113
      OR target MATCHES "^(x86_64|aarch64)")
    set(${result} TRUE PARENT_SCOPE)
  else()
    set(${result} FALSE PARENT_SCOPE)
  endif()
endfunction()

```

If we decide to allow `REAL(16)` on many more targets, would we need to hardcode all supported targets here as well?

Alternatively, we could use a mechanism similar to `FlangRTIntrospection.cmake`, which determines whether the frontend can actually compile `REAL(16)` code and sets `FORTRAN_SUPPORTS_REAL16` accordingly. However, my understanding is that during bootstrap builds a mock Flang is used, and therefore `check_fortran_source_compiles()` is not executed:

FlangRTIntrospection.cmake:
https://github.com/llvm/llvm-project/blob/7a732b1ccfbf9694aad53817ebd47d29335590bc/flang-rt/cmake/modules/FlangRTIntrospection.cmake#L17-L28

Am I missing another mechanism that could keep the runtime and frontend decisions in sync during bootstrap builds?

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