[Mlir-commits] [mlir] [mlir] Add FP software implementation lowering pass: `arith-to-apfloat` (PR #166618)

[Matthias Springer]

================
@@ -0,0 +1,120 @@
+//===- ArithToAPFloat.cpp - Arithmetic to APFloat Conversion --------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#include "mlir/Conversion/ArithToAPFloat/ArithToAPFloat.h"
+
+#include "mlir/Dialect/Arith/IR/Arith.h"
+#include "mlir/Dialect/Arith/Transforms/Passes.h"
+#include "mlir/Dialect/Func/IR/FuncOps.h"
+#include "mlir/Dialect/Func/Utils/Utils.h"
+#include "mlir/IR/PatternMatch.h"
+#include "mlir/IR/Verifier.h"
+#include "mlir/Transforms/WalkPatternRewriteDriver.h"
+
+namespace mlir {
+#define GEN_PASS_DEF_ARITHTOAPFLOATCONVERSIONPASS
+#include "mlir/Conversion/Passes.h.inc"
+} // namespace mlir
+
+using namespace mlir;
+using namespace mlir::func;
+
+/// Helper function to look up or create the symbol for a runtime library
+/// function for a binary arithmetic operation.
+///
+/// Parameter 1: APFloat semantics
+/// Parameter 2: Left-hand side operand
+/// Parameter 3: Right-hand side operand
+///
+/// This function will return a failure if the function is found but has an
+/// unexpected signature.
+///
+static FailureOr<Operation *>
+lookupOrCreateBinaryFn(OpBuilder &b, Operation *moduleOp, StringRef name,
+                       SymbolTableCollection *symbolTables = nullptr) {
+  auto i32Type = IntegerType::get(moduleOp->getContext(), 32);
+  auto i64Type = IntegerType::get(moduleOp->getContext(), 64);
+  return lookupOrCreateFnDecl(b, moduleOp,
+                              (llvm::Twine("_mlir_apfloat_") + name).str(),
----------------
matthias-springer wrote:

> What I meant is, if you had 2 different kind of unsupported types and an add, wouldn't _mlir_apfloat_add be used for both?

That's correct. At moment, all FP values are bitcasted to integer values of the same bit width and then zero-extended to 64-bits, so that the same function can be used for all FP types with <= 64 bit width.

> So at least we should mangle on width.

If we mangle based on the bitwidth, we can save some `arith.exti` / `arith.trunci` ops, at the expense of blowing up the number of runtime functions by a factor of of 5 (supported bitwidths: 4, 8, 16, 32, 64). It's a tradeoff...


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