[flang-commits] [flang] [mlir] [RFC][mlir] Conditional support for fast-math attributes. (PR #125620)

[Jakub Kuderski via flang-commits]

kuhar wrote:

> Please also note that this patch does not add fast-math support to `arith.select`, it just adds support for conditional fast-math support in general and for operations of HLFIR dialect. I appreciate the discussion about `arith.select`, but I just want to understand if you are also proposing some changes to the current patch - can you please clarify?

Sorry, I was mostly thinking out loud and did not mean to derail this PR. I'm trying to understand the goal stated in the PR description:
> This is inspired by https://llvm.org/docs/LangRef.html#fastmath-return-types and my goal to add fast-math support for arith.select operation that may produce results of any type.

I'd not expect `arith.select` to know anything about fast math because of the reasons mentioned above in https://github.com/llvm/llvm-project/pull/125620#issuecomment-2634482765. Separately, fast math in clang/llvm is known to be broken and I'd like to make sure we are not working backwards from the solution and invertedly repeat the same mistakes. For example, see this issue: https://github.com/iree-org/iree/issues/19743. I will set aside some time to read the llvm discussion that you linked and understand their design better.

>  It seems that what you are proposing depends on whether the operands' arith.assume definitions are always reachable from arith.select, but it may not be true with block arguments. So having arith.select to carry fast-math seems more robust to me.

I'd think that the real implementation can have a matcher that checks if `arith.select` operands are `<insert-your-favorite-fmf-assumption>`, and frontends can insert these `assumef` ops to communicate this in the absence of anything else that would imply it.


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