[Mlir-commits] [mlir] [MLIR][LLVMIR] Add an operation to handle constrained FP intrinsics (PR #199754)

[Tobias Gysi]

gysit wrote:

> We could handle it that way. As you say, the difficulty is in representing the metadata arguments. I don't like the idea of reusing the existing CallIntrinsicOp with a caveat that some of the arguments are attached as attributes, and I don't know of a way to directly model metadata arguments in MLIR. I also don't like the idea of adding the FPExceptionBehaviorOpInterface and RoundingModeOpInterface to the general operation when it won't apply to most intrinsics.

The goal of `CallIntrinsicOp` is to be able to model any LLVM intrinsic, from that perspective I would be fine with adding more interfaces in addition to the already present `FastmathFlagsInterface`. That approach would rely on all metadata arguments having a unique metadata kind which may not be flexible enough for the generic `CallIntrinsicOp`. An alternative may be to have a helper operation that can be used to model metadata arguments (basically an operation that takes an attribute (the converted metadata) and returns an SSA value that is consumed by the `CallIntrinsicOp`). 

> Dropping "Call" from the name makes sense to me. I did intend to be able to support the currently supported constrained intrinsics using this new operation, but I wasn't sure if there would be any out-of-tree impact to removing the existing operations.

I would vote for a full replacement rather than having multiple ways of representing the same operation. The `CallIntrinsicOp` is the exception for that rule since it is the fallback path for unsupported intrinsics. As long as the new operation is feature complete this is hopefully ok for out-of-tree users. But it is true that the explicit operations have better ergonomics. 

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