qiucf added a comment. 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? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D92080/new/ https://reviews.llvm.org/D92080 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
