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.
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.
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?