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

[Andy Kaylor]

andykaylor wrote:

> I believe this deserves an RFC on the LLVM/MLIR discourse since it is quite an intrusive change.

Yes, sorry. I should have linked to that, but I see now @vzakhari has done that for me.

> To make sure I understand correctly. Does this PR prefetch upcoming changes in LLVM proper? If so, that would contradict the core rationale of the MLIR LLVM dialect, which is meant to closely mirror LLVM IR as it exists today.

I don't know if there is a timeline for the changes in LLVM IR. There seems to be some consensus around the proposal, but that will require a lot of changes to existing optimizations. I would be surprised if it doesn't take at least a year to get the new representation in place there.

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.

> Additionally, the translation layer to LLVM IR is already quite complex. Adding extra legalization logic there further increases complexity. Would it be possible to handle this through a separate, higher-level dialect that models these constraints and then lowers directly to the existing LLVM dialect constraint intrinsics instead? Once LLVM proper implements the changes, we can pull these changes into LLVM dialect.

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.

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