These tests fail when the default is switched to assume IEEE denormal
handling. I'm not sure if PPC really has a way to control the denormal
Sanity check failed with the updated case. (Depending on other patches ?)
llvm/llvm/test/CodeGen/PowerPC/qpx-recipest.ll:320:15: error: CHECK-NEXT: expected string not found in input ; CHECK-NEXT: addis 3, 2, .LCPI12_2@toc@ha ^ <stdin>:470:2: note: scanning from here qvfmul 0, 0, 1 ^ <stdin>:470:3: note: possible intended match here qvfmul 0, 0, 1
Well, it seems that it is still too early to review this change. One comments: I see that, we have the code sequence change if switch to ieee. sqrt_afn_ieee is slower than sqrt_afn. As you are trying to set it as ieee for target that didn't explicit set the denormal-fp-math, which means that, this will affect PowerPC. Could we have the Frontend set the denormal-fp-math for PowerPC as non-ieee, so that, you don't need this patch any more ?
Based on the comments in bug 34994, the current behavior is broken on PowerPC. Denormals are enabled by default, so the sqrt expansion is broken. It would be incorrect to default to non-ieee
Bugzilla appears to be dead currently, so I can't check exactly what was written there, but that's what I remember too.
Note that PowerISA rev 2.07 (not sure what current state is) has a bit in the FPSCR that is likely relevant:
Bit 61 - Floating-Point Non-IEEE Mode (NI) Programming Note: When the processor is in floating-point non-IEEE mode, the results of floating-point operations may be approximate, and performance for these operations may be better, more predictable, or less data-dependent than when the processor is not in non-IEEE mode. For example, in non-IEEE mode an implementation may return 0 instead of a denormalized number, and may return a large number instead of an infinity.
I have no idea if/how any recent PPC implementation makes uses of that bit. And I don't know if any compiler sets that bit using tricks (like x86 might).
LGTM, but someone closer to PPC should approve officially.
Is the intent to leave this file as-is (no explicit denormal attributes) to show default behavior? Alternatively, we could specify the attribute and decouple this patch from the other patches in this series?
This seems straightforward to me - I assume the constant pool load in the test case is some value denoting the smallest normal value for the type. Then rather than comparing against zero do determine when to return zero, we compare against that value (after taking the absolute value).
So if I understand the test case updates correctly, LGTM.