[flang-commits] [flang] [mlir] [mlir][math] Replace roundeven call by nearbyint call when target does not have C23 features (PR #88687)

[Frederik Harwath via flang-commits]

================
@@ -185,8 +186,15 @@ void mlir::populateMathToLibmConversionPatterns(RewritePatternSet &patterns) {
   populatePatternsForOp<math::Log10Op>(patterns, ctx, "log10f", "log10");
   populatePatternsForOp<math::Log1pOp>(patterns, ctx, "log1pf", "log1p");
   populatePatternsForOp<math::PowFOp>(patterns, ctx, "powf", "pow");
-  populatePatternsForOp<math::RoundEvenOp>(patterns, ctx, "roundevenf",
-                                           "roundeven");
+  if (options.allowC23Features)
+    populatePatternsForOp<math::RoundEvenOp>(patterns, ctx, "roundevenf",
+                                             "roundeven");
+  else if (options.roundingModeIsDefault)
+    populatePatternsForOp<math::RoundEvenOp>(patterns, ctx, "nearbyintf",
+                                             "nearbyint");
+  // Roundeven: using nearbyint (pre-C23) for roundeven requires the
----------------
frederik-h wrote:

> My use case is indeed a C compiler that does not support (yet) roundeven. It comes with its own libm implementation that does not feature this function.

So this is a workaround for a missing implementation of `roundeven` in your libm? Some thoughts about alternative solutions: (1) Implement it in your libm, (2) keep this change in your projects fork of mlir until you implement it if that exists, or (3) add a `math.nearbyint` and document that its behavior depends on a target specific rounding mode (assuming that this would be at least as acceptable for the `math` dialect as the changes from this PR) and then replace `math.roundeven` by that in a pass in your front end? (3) sounds like the best approach to me assuming that (1) is not an option for you right now, but we would need the opinion of someone who is more familiar with the design goals of the dialect.

https://github.com/llvm/llvm-project/pull/88687