landing on this PR, from the conclusion of #55230 and D158632 conversation..
"If the llvm.fmuladd intrinsic reaches the backend, the backend is responsible for deciding how to represent it."

ping!

ping!

In D158632#4619452, @arsenm wrote:

This is a frontend solution to a backend problem. Fmuladd does not guarantee fusion or not and that’s all you have changed the emission of. Clang should not be considering the target for what it should emit. -fp-contract=on emits fmuladd and -fp-contract=fast emits fmul contract fadd contract.

The backend is responsible for deciding whether it’s profitable to fuse or not, where it’s also refined based on the FP type

ping!

@nemanjai , @jhibbits should i land on this commit, because as @shchenz said, similiar to D158632 review we are having plan to do same for PPC.

bisecting testcase fexcess-precision.c for default subtarget and AVX512-FP16, because update script update_cc_test_checks.py was removing some checks because of same -check-prefixes..

updating according to ATR-PASS-COMPLEX-IN-GPRS.
Thanks @kernigh!

In D146942#4581157, @kernigh wrote:

Thanks, @long5hot. Your diff fixes compatibility with gcc for some functions. These 2 functions are broken,

float complex
scale1(int n, float complex c)
{
	return n * c;
}

double complex
scale2(int n, double complex c)
{
	return n * c;
}

The compilers differ at r4,

• gcc does scale1(int r3, float complex r5:r6) and scale2(int r3, double complex r4:r5:r6:r7). See https://godbolt.org/z/xjdWaWP3q
• clang -fcomplex-ppc-gnu-abi does scale1(int r3, float complex r4:r5) and scale2(int r3, double complex r5:r6:r7:r8).

So gcc is weird; the alignment of complex arguments in gprs doesn't match their alignment in memory. A 2x32-bit float complex has 64-bit alignment (skip r4) but a 2x64-bit double complex has 32-bit alignment (don't skip r4). This is an accident, as gcc confuses complex args with integer args: a float complex has the same 64-bit size as a long long, so gcc applies long long's rule (odd:even gpr pair); a double complex has a different size and misses the odd:even rule.

In D156344#4583559, @shchenz wrote:

compiler-rt builtins library should not just undefining fma for PPC, right (see https://gcc.gnu.org/onlinedocs/gccint/Soft-float-library-routines.html)? If so, maybe we should at least first try not generating fma for soft-float at the first place where fmul + fadd is fused, like tryEmitFMulAdd in clang front end?

The revision till now was working for release build only.
Wasn't aware of round-trip in assert-build.
Updating accrodingly.

ping!

failure is only when we do not give full target triple.
for e.x. --target=ppc64 -mabi=elfv2
or even when OS option is unknown e.g. --target=powerpc64-unknown-gnu

Apologies for updating diff too many times, used arcanist first time. Won't happend again!

addressing @DavidSpickett's comments..

Extra check regarding ELF.

ping!

changing sequence(order) of arguments in testcase because of failure.

Removin Lambda expression.

updating testCase

-fcomplex-ppc-gnu-abi switch .

In D152437#4434132, @long5hot wrote:

In D152437#4433280, @jhibbits wrote:

Looks good to me, thanks!

@jhibbits Can you please help to commit the changes??

In D152437#4433280, @jhibbits wrote:

Looks good to me, thanks!

removal of lambda expression from conditional statement, and updated existent test case.