Page MenuHomePhabricator

[Clang] Mutate long-double math builtins into f128 under IEEE-quad
ClosedPublic

Authored by qiucf on Nov 25 2020, 12:51 AM.

Details

Summary

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.

Diff Detail

Event Timeline

qiucf created this revision.Nov 25 2020, 12:51 AM
Herald added a project: Restricted Project. · View Herald TranscriptNov 25 2020, 12:51 AM
qiucf requested review of this revision.Nov 25 2020, 12:51 AM

gcc calls the *l version with -mlong-double-128 on x86. Should we match gcc here?

qiucf added a comment.Nov 25 2020, 7:31 PM

gcc calls the *l version with -mlong-double-128 on x86. Should we match gcc here?

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?

qiucf added a comment.Dec 3 2020, 7:27 PM

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.

yubing added a subscriber: yubing.Dec 10 2020, 7:42 AM
qiucf added a comment.Dec 11 2020, 1:20 AM

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?

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?

qiucf updated this revision to Diff 312153.Dec 16 2020, 1:23 AM
qiucf edited the summary of this revision. (Show Details)
  • Diff based on pre-commit
  • Restrict to PPC64
qiucf added a comment.Dec 16 2020, 1:25 AM

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?

Ah, yes. I should keep it as PPC64-only here, with TODO comments for it.

LGTM but a PPC-guru needs to signoff

nemanjai accepted this revision.Thu, Jan 14, 4:51 AM

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.

This revision is now accepted and ready to land.Thu, Jan 14, 4:51 AM