[PATCH] D149587: InstSimplify: Simplifications for ldexp

[Jay Foad via Phabricator via llvm-commits]

foad added inline comments.


================
Comment at: llvm/lib/Analysis/InstructionSimplify.cpp:6084
+    if (Q.isUndefValue(Op0))
+      return ConstantFP::getNaN(Op0->getType());
+
----------------
arsenm wrote:
> arsenm wrote:
> > foad wrote:
> > > arsenm wrote:
> > > > foad wrote:
> > > > > Why is this not strictfp-safe?
> > > > If undef resolved to a signaling nan it wouldn't raise an exception
> > > But here you are //choosing// what you want the undef value to be, so choose a quiet NaN.
> > https://github.com/llvm/llvm-project/blob/67a212af4c24426de6e436e9b82590d41faa665c/llvm/lib/Analysis/InstructionSimplify.cpp#L5513
> > 
> > This is checking this which is a more refined check of strictfp
> although really I should probably just call simplifyFPOp in the first place
> https://github.com/llvm/llvm-project/blob/67a212af4c24426de6e436e9b82590d41faa665c/llvm/lib/Analysis/InstructionSimplify.cpp#L5513
Well I don't understand why that code doesn't propagate quiet NaNs unconditionally. I agree with @sepavloff's comment: https://reviews.llvm.org/D103169#inline-979968

Also, that code handles all fp ops but here we only care specifically about ldexp. Where is the spec for what fp exceptions ldexp can raise? `man ldexp` mentions exceptions on overflow and underflow, but does not mention raising invalid operation even on a signalling NaN input.

In any case a comment explaining why each case is supposedly not fpstrict-safe would really help, since this stuff is massively non-obvious.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D149587/new/

https://reviews.llvm.org/D149587