[flang-commits] [flang] [mlir] [RFC][mlir] Conditional support for fast-math attributes. (PR #125620)
Slava Zakharin via flang-commits
flang-commits at lists.llvm.org
Fri Feb 7 12:26:15 PST 2025
vzakhari wrote:
> `arith.select` is a conditional move op and should never change the value of either operand.
I am not sure I understand how fast-math attributes attached to `arith.select` imply that it can change the value of either operand - can you please clarify?
> Ops like `arith.select` and block arguments are changed repeatedly throughout many pipelines and preserving (or even knowing how to set) fast math information is not feasible (or useful).
Isn't it true for any other discardable attribute? In my opinion, the transformations should drop any attributes that they don't know about or preserve any attribute that they know about (generic attribute interfaces may ease the handling here). Otherwise, how we can guarantee that a discardable attribute propagated during op->op transformation, without paying attention to preserving the attribute semantics, is still valid in the MLIR after the transformation?
I created https://discourse.llvm.org/t/rfc-arithfastmathinterface-support-for-arith-select/84508 for further discussion of the fast-math flags on `arith.select`. Can we please continue there?
I think the discussion here should be about conditional support of fast-math attributes on operations that support the fast-math interface. I believe the HLFIR case is a good example where such support makes sence.
> If lowering into LLVM needs this information then it should perform analysis to determine the required information
I do not think it is always possible (see example in the above discourse RFC).
https://github.com/llvm/llvm-project/pull/125620
More information about the flang-commits
mailing list