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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
