[PATCH] D155546: [clang][Interp] Implement __builtin_fmin

[Joshua Cranmer via Phabricator via cfe-commits]

jcranmer-intel added inline comments.


================
Comment at: clang/test/AST/Interp/builtin-functions.cpp:65-73
+  constexpr float f1 = __builtin_fmin(1.0, 2.0f);
+  static_assert(f1 == 1.0f, "");
+
+  constexpr float min = __builtin_fmin(__builtin_nan(""), 1);
+  static_assert(min == 1, "");
+  constexpr float min2 = __builtin_fmin(1, __builtin_nan(""));
+  static_assert(min2 == 1, "");
----------------
aaron.ballman wrote:
> jcranmer-intel wrote:
> > tbaeder wrote:
> > > aaron.ballman wrote:
> > > > Can you add a test using `__builtin_nans` to show that it results in an invalid constant expression because of the `FE_INVALID` signal?
> > > It doesn't currently result in an invalid constant expression in clang (both new and current interpreter). Where should that signal occur? Or do I need to check for signaling nans whenever I compute a floating value?
> > Most, but not all, floating-point operations with an sNaN signal an exception. The complete list of exceptions is, I believe:
> > 
> > - C2x 7.12.3 classification macros (e.g., `isnan`, `fpclassify`)
> > - totalorder, totalordermag
> > - fneg, fabs, copysign, "copy" (basically anything that could do an SSA copy of the value)
> > - conversion to/from strings, maybe (IEEE 754 has some "should"s in here)
> > 
> > The best place to do the checking for sNaNs is where you're handling the inputs for a function.
> > 
> > (As a brief aside, C++23 only discusses making FP exceptions compile-time errors for calling C library functions, not regular floating-point exceptions.)
> That's the way that I would approach it (to check for a signaling NaN any time you need its value) and I think that's the same as the suggestion from @jcranmer-intel.
> not regular floating-point exceptions.

That should say "regular floating-point operations" (e.g., `a + b`).


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

https://reviews.llvm.org/D155546