[Mlir-commits] [mlir] [mlir][llvmir] Add new support for strict fp handling (PR #205158)

[Tobias Gysi]

gysit wrote:

> My hope with this proposal is to get an implementation in place in the various MLIR dialects mentioned in the RFC that maps to the (10-year-old) experimental constrained intrinsics and then update the lowering to LLVM IR when the new form is in place there.

Normally the idea is to keep LLVM dialect in sync with LLVM IR. There are some exceptions though and there is the option to run a legalization pass before the actual lowering that creates the LLVM IR compatible intrinsics before converting to LLVM IR. 

> I did consider having the arith and CIR dialects use the representation proposed in this PR and then have those lower to constrained intrinsic calls when lowering to the LLVM dialect similar to how arith handles rounding mode today for a limited number of instructions. That is, of course, still possible. It seemed cleaned to me to isolate the wrapping of the old/existing LLVM IR representation in the translation layer, but if the use of the attribute and interface I am proposing here is only used by the arith and CIR dialects, it wouldn't be much extra work to update the lowering of those dialects to the LLVM dialect later when the new representation is finished in LLVM IR.

I believe from my perspective implementing the new semantics in Arith dialect and then lower to the constraint intrinsics in LLVM dialect is a nicer lowering story, where the individual lowerings have a smaller abstraction gap. Additionally, the LLVM dialect remains a direct copy of the LLVM IR for the time being. Note that the Arith dialect is the place to design and implement higher level abstractions and optimizations. LLVM dialect is really only meant as an egress dialect.

There is the long term vision that Arith dialect ultimately could lower to LLVM IR directly by implementing the LLVM translation interface (similar to how the target specific intrinsics are lowered). That way LLVM dialect would not need arithmetic operations itself, and we would avoid all the duplication of operations and interfaces that we have today (for example, there are two fast math interfaces). That being said, there has not much work been done in this direction, so that vision may never materialize.



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