[PATCH] D22685: Disable shrinking of SNaN constants on SystemZ

[Ulrich Weigand via llvm-commits]

uweigand added a comment.

In https://reviews.llvm.org/D22685#496030, @colpell wrote:

> Hmm, that definitely explains why x86 isn't running into this issue.
>  In that case, is the general approach of not shrinking SNaNs in the first place better, or would it make sense to add more special code to APFloat to avoid "inexact" conversions on SystemZ as well?
>  My feeling is that more backend-specific in APFloat is a bit messy, though it has the potential to fix other cases where we're converting a SNaN (not that I'm currently aware of any).


Thinking about that, I'm not sure whether the APFloat.convert behavior is really correct.  In many cases, it is possible to convert a SNaN in to another SNaN in a different format exactly.  (Not all cases, of course.  Also, the x86 extended format "pseudo-NaNs" are really special, and can never be converted exactly.)

But simply never doing constant shrinking of a signaling NaN seems the best way to me right now ...

> Here's some example code that results in a "shrunk" SNaN load:


[snip]

> This will print `7ffc000000000000` with trunk Clang, but will print `7ff4000000000000` with GCC or with my patch applied.


Well, I can reproduce thie 7ffc... result, but only with -m32 and with no optimization.  But under those circumstances, I see it with both clang and gcc.

What happens here is that the (non-inlined) call to signaling_NaN() returns an SNaN in the 80-bit extended format in %fp(0) according to the 32-bit floating-point ABI.  Code then stores this value to a 64-bit stack slot using FSTPL.  *This* instruction is what converts the extended SNaN into a double-precision QNaN (and also sets the inexact exception flag).  But that's completely separate issue from constant shrinking ...


https://reviews.llvm.org/D22685