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

[Shunsuke Watanabe via flang-commits]

s-watanabe314 wrote:

> Instead, it suggests to use `TargetLoweringBase::getTypeAction(Ctx, MVT::f128)`, ` getOperationAction(ISD::FADD, MVT::f128)`, `TLI->getLibcallName(RTLIB::ADD_F128)` (does not check the existance of the library, but whether TLI configured the runtime function besed on the `-target` triple), `clang::TargetInfo::hasFloat128Type()` (Clang only, may need our on version in TargetCharacteristics).
> 
> Cases to consider:
> 
> * i386: false for `isTypeLegal(f128)`, but has `__addtf3` libcall
> * NVPTX: has no runtime call it could fall back to

Thanks for pointing out the i386 and NVPTX cases, and for the suggestions on backend-side queries. I checked the return values of `isTypeLegal`, `getTypeAction`, `getOperationAction`, and `getLibcallName` for a number of targets and got the following results:

| -fc1 -triple | isTypeLegal(fp128EVT) | getTypeAction(ctx, f128VT) | getOperationAction(ISD::FADD, f128VT) | getLibcallName(RTLIB::ADD_F128) |
|--------------|-----------------------|----------------------------|---------------------------------------|----------------------------------|
| aarch64      | 1 | TypeLegal       | LibCall | __addtf3 |
| amd64        | 1 | TypeLegal       | LibCall | __addtf3 |
| amdgpu       | 0 | TypeSoftenFloat | Legal   |          |
| i386         | 0 | TypeSoftenFloat | Legal   | __addtf3 |
| i486         | 0 | TypeSoftenFloat | Legal   | __addtf3 |
| i586         | 0 | TypeSoftenFloat | Legal   | __addtf3 |
| i686         | 0 | TypeSoftenFloat | Legal   | __addtf3 |
| i786         | 0 | TypeSoftenFloat | Legal   | __addtf3 |
| i986         | 0 | TypeSoftenFloat | Legal   | __addtf3 |
| nvptx64      | 0 | TypeSoftenFloat | Legal   |          |
| powerpc      | 0 | TypeSoftenFloat | Legal   | __addkf3 |
| ppc          | 0 | TypeSoftenFloat | Legal   | __addkf3 |
| riscv64      | 0 | TypeSoftenFloat | Legal   | __addtf3 |
| sparc        | 1 | TypeLegal       | Custom  | _Q_add   |
| sparc64      | 1 | TypeLegal       | Custom  | _Qp_add  |
| systemz      | 1 | TypeLegal       | Legal   | __addtf3 |
| x86_64       | 1 | TypeLegal       | LibCall | __addtf3 |

The full results are available here:
https://gist.github.com/s-watanabe314/351e29c3f8f6ce9058cf6941e69ecb2b

Based on these results, `getLibcallName(RTLIB::ADD_F128)` seems to be the only one of these checks that clearly distinguishes targets such as i386 (which can still lower fp128 arithmetic through runtime calls) from nvptx64 (which appears to have no such fallback path).

Would using the availability of the relevant F128 libcalls (e.g. ADD_F128/SUB_F128/MUL_F128/DIV_F128) as the criterion for REAL(16) frontend availability sound reasonable to you?



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