Under -mabi=ieeelongdouble on PowerPC, IEEE-quad floating point semantic is used for long double. This patch mutates call to related builtins into f128 version.
Details
- Reviewers
craig.topper spatel nemanjai jsji steven.zhang kpn RKSimon efriedma hfinkel - Group Reviewers
Restricted Project - Commits
- rG168be4208304: [Clang] Mutate long-double math builtins into f128 under IEEE-quad
Diff Detail
Event Timeline
Ah, yes, so this should be PPC-only change.
But I see under x86 -mlong-double-128, std functions (printf/sqrtl/...) can't provide correct results (seems they're just for fp80). Is this expected?
Any comments...? I don't have knowledge if there's any plan about implementing *f128 math functions on X86 libcs. But as I see so far, *l doesn't work well on fp128. Keeping this target independent currently seems reasonable to me.
Please can you pre-commit math-builtins-adjust.c with current IR checks and then rebase to show the diffs? Maybe rename it math-builtins-long.c as well?
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). 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 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?
LGTM.
I think it would be useful to run a functional test with a toolchain that has these library functions. That shouldn't gate this change though.
clang-format: please reformat the code