[Mlir-commits] [mlir] [MLIR][Parser] Fix precision loss when parsing f80 and f128 literals (PR #220267)

[Matthias Springer]

================
@@ -401,21 +402,27 @@ ParseResult Parser::parseFloatFromLiteral(std::optional<APFloat> &result,
                                           const llvm::fltSemantics &semantics) {
   // Check for a floating point value.
   if (tok.is(Token::floatliteral)) {
-    auto val = tok.getFloatingPointValue();
-    if (!val)
-      return emitError(tok.getLoc()) << "floating point value too large";
-
     // A type with no signed representation, such as f8E8M0FNU, has no encoding
-    // for this value at all; the conversion below would keep the sign bit and
+    // for this value at all; negating below would keep the sign bit and
     // produce a value that asserts when it is printed.
     if (isNegative && !APFloat::semanticsHasSignedRepr(semantics))
       return emitError(tok.getLoc())
              << "negative floating point literal for a type with no signed "
                 "representation";
 
-    result.emplace(isNegative ? -*val : *val);
-    bool unused;
-    result->convert(semantics, APFloat::rmNearestTiesToEven, &unused);
+    // Parse with the requested semantics directly. Going through a double
+    // first would lose range and precision for wider semantics, such as f80.
+    APFloat value(semantics);
+    llvm::Expected<APFloat::opStatus> status = value.convertFromString(
+        tok.getSpelling(), APFloat::rmNearestTiesToEven);
+    if (!status) {
+      llvm::consumeError(status.takeError());
+      return emitError(tok.getLoc()) << "invalid floating point literal";
+    }
----------------
matthias-springer wrote:

When would you see `invalid floating point literal`? A float literal token should always be parseable by `APFloat`, should this be an `assert`?

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