[RFC] FastMath flags support in complex dialect

MLIR
1

Motivation

During the discussion through supporting some type of canonicalization for complex dialect, we have found it’s necessary (and straight forward) to support FastMath flag beforehand if we want to run the canonicalization which needs to take into consideration nan, infs. Some optimization passes need the clearer semantics of how we treat mathematical operations.

The same discussion happened for arith dialect before. We have discovered this is also the case for complex dialect.

As pointed before, there is some ambiguity how we treat floating-point lowering depending on the path we take (ComplexToLLVM vs ComplexToStandard)

In this RFC, we are proposing to support FastMath flag for complex.dialect ops which allows the canonicalization and other optimization passes to keep the intention properly. We basically assume we had already have the similar discussion when supporting the FastMath flag in arith dialect. If there is something we have to take care specially for the complex dialect, let’s talk about it.

Considerations

  • It should be feasible to limit the scope of fast-math flag in the complex dialect context because the flag for the non-arithmetic op (e.g. select) are mostly used for optimization purpose. As discussed in the previous RFC for arith dialect, the current MLIR framework can do such optimization on known-function without supporting fast-math attribute
  • We may want to support the FastMath flag capability in more general and broader way (e.g. builtin). That will allow us to reuse the flag capability in multiple levels. To achieve that, it would be better to have the umbrella flag modeling the FFP behavior applicable across MLIR like clang, which should be able to control the dialect specific FastMath flag behavior in a comprehensive manner. Therefore supporting the dialect specific FastMath flag can be done first and progressively supported by the umbrella flag if needed.

Proposed Changes

  • Create FastMathFlags attribute as EnumAttr as an optional attribute as we did for arith dialect.
  • Define ComplexFastMathInterface interface which is supposed to be implemented by the operation supporting FastMathFlags
  • Add optional FastMathFlags attribute to floating-point operations (e.g. complex.MulOp) and path the flag to lowered arith operation
  • Progressive addition of fast-math aware transform/conversion/canonicalization for floating point operation from complex to Arith or LLVM.
    • We can make use of AttrConvert prepared in the arith fast-math support.
    • Conversion mapping for the flags can be idential with the arith dialect

Discussions

  • A complex op is lowered or converted to multiple arith ops (e.g. complex.MulOp). Does it make sense to pass the same fastmath flag to all the lowered operations?
    • For instance, complex.MulOp is lowered to the combination of arith.MulFOp, arith.OrI, arith.XOrI etc. Is it semantically reasonable to pass the same fastmath flag to all the lowered operations?

Initial Diff

https://reviews.llvm.org/D156310

References

1 Like
2

Thanks @Lewuathe for the proposal. This will also benefit Flang where we use the Complex Math ops when FastMath is switched ON.

  • Create FastMathFlags attribute as EnumAttr as an optional attribute as we did for arith dialect.
  • Define ComplexFastMathInterface interface which is supposed to be implemented by the operation supporting FastMathFlags

I think we already reuse the definitions in arith dialect in the math dialect. Can we do the same here rather than defining the FastMathFlags again?

  • A complex op is lowered or converted to multiple arith ops (e.g. complex.MulOp ). Does it make sense to pass the same fastmath flag to all the lowered operations?

I think they should be propagated to the Floating point operations. Do you see any issues here?

3

I don’t have concerns with the plan in general, but I just wanted to point Place for fastmath attributes ; in short I’m quite concerned about creating more fast math flags attributes, and I would like to see us having a single one instead (it is fine if LLVM Dialect keeps its own one).

1 Like
4

I agree with you as I don’t any issue to propagate the flag to all the lowered arithmetic or LLVM floating operation. It should be simple and straightforward.

5

Thank you for giving me the previous discussion. I totally agree with the idea to consolidate all fastmath flags in one place as there is no divergence from LLVM ones for now. Can we put them in the built in attribute?

6

I expect some folks to object to adding anything to builtin, the bar is really high there.

7

Why do you want to invent something that does not make my eyes blink. You already have a dependency on Arith: