[PATCH] D92080: [Clang] Mutate long-double math builtins into f128 under IEEE-quad

Fri Dec 11 10:12:13 PST 2020

craig.topper added a comment.

In D92080#2448094 <https://reviews.llvm.org/D92080#2448094>, @qiucf wrote:

> In D92080#2443333 <https://reviews.llvm.org/D92080#2443333>, @craig.topper wrote:
>
>> I don't think I understand the whole picture here. Why would only builtins get mutated? Does a call to "modf" still call "modf"? But __builtin_modf will call modf128? Is there a corresponding patch to the runtime libcalls table in the backend? With -ffast-math __builtin_sinl becomes llvm.sin.f128 and the backend will emit a call to sinl if ISD::SIN isn't legal.
>
> We're going to make IEEE `f128` available in Clang on ppc64le. Newest glibc already supports 'redirection' from `fmodl` to `fmodf128` (or, `__fmodieee128`) by checking some macros determined by current long-double semantics. For these LLVM intrinsics, Steven has a patch to fix the correct signature of libcall (D91675 <https://reviews.llvm.org/D91675>). Builtin in Clang will generate intrinsics under `ffast-math` but function call without the option. That may lead to an awkward situation: program is correct under fast-math, but wrong under no optimization. So such mutation is needed.
>
> This patch looks reasonable to me for targets with more than one long-double format. Or if that's not a right way for the mutation, are there other places to implement that?

D91675 <https://reviews.llvm.org/D91675> has PowerPC only changes to make the f128 calls get emitted. If you change the frontend in a target independent way as proposed here, won't that make the frontend and backend not match for targets like X86?

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D92080/new/

https://reviews.llvm.org/D92080