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

[Matthias Springer]

matthias-springer wrote:

> So, I'm curious as to what's the ultimate goal. Hopefully not to just leave it as is.

This PR just sets up the infrastructure. Once this is merged, we can work on this in parallel. I'd like to add support for all `arith` dialect ops and potentially some `math` dialect ops over time. (As long as it's supported by APFloat.)

I have two internal use cases for this: (1) compiler verification by running the same program on CPU/GPU and comparing the result. (2) Filtering out fuzzer-generated programs before sending them to the GPU to execute. Sanitizers work better on CPU. (Basically same approach as Triton-San, which was presented at LLVM Dev 2025.)

Also one external use case: The code quality of the APFloat implementation is not very good and there may be bugs in the implementation. By comparing GPU/CPU results, we could find such bugs. (If there are any.)

> I also imagine this is one of those passes that are done right at the end of the pipeline, in case nothing else covers float semantics. How can we show it interoperates well with the existing LLVM lowering passes?

I extended the integration test to show two scenarios: (1) All arithmetics lowering to APFloat. (2) Only unsupported arithmetics lowering to APFloat.

> what if we add a proper soft-float implementation, what would be the runtime footprint, given it will be mostly unused?

Haven't thought about it much, but if we would want this to work platform-independently (i.e., also on GPU, etc.), we could reimplement what APFloat is doing with `arith` dialect ops: a lot of bit-level manipulation (shifting, etc.).

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