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

[Elliot Colp via llvm-commits]

colpell added a comment.

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

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

  #include <iostream>
  #include <limits>
  
  int main()
  {
     double snan = std::numeric_limits<double>::signaling_NaN();
     long long *p = (long long *)(&snan);
     std::cout << std::hex << *p << '\n';
     return 0;
  }

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


https://reviews.llvm.org/D22685