Page MenuHomePhabricator

PPC: Prepare tests for switch of default denormal-fp-math
ClosedPublic

Authored by arsenm on Nov 7 2019, 6:31 PM.

Details

Reviewers
hfinkel
nemanjai
spatel
kbarton
steven.zhang
Group Reviewers
Restricted Project
Summary

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
input handling.

Diff Detail

Event Timeline

arsenm created this revision.Nov 7 2019, 6:31 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 7 2019, 6:31 PM
Herald added subscribers: jsji, wdng. · View Herald Transcript
jsji added a reviewer: Restricted Project.Nov 8 2019, 8:23 AM

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
steven.zhang requested changes to this revision.Nov 14 2019, 5:18 PM
This revision now requires changes to proceed.Nov 14 2019, 5:18 PM

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

Yes, I added the dependencies

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 ?

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

steven.zhang resigned from this revision.Nov 14 2019, 7:21 PM

Ok, https://reviews.llvm.org/D42323 is the background for this patch. I will leave this to others to continue the review as I am not familiar with floating stuff.

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.

llvm/test/CodeGen/PowerPC/qpx-recipest.ll
303

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?

nemanjai accepted this revision.Dec 27 2019, 4:38 AM

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.

This revision is now accepted and ready to land.Dec 27 2019, 4:38 AM