In general, the meaning of fastmath flags on a call during inlining
is that the call's operation flags must be ignored. For user functions
that means that the fastmath flags used for the function definition
override any call site's fastmath flags. For intrinsic functions
we can use the call site's fastmath flags, but we have to make sure
that the call sites with different flags produce/use different
simplified versions of the same intrinsic function.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Note that this only works for dot_product now. If it looks okay, I will extend it to other cases.
Looks good to me. Have you considered having the flag copy part happening in fir::FirOpBuilder builder(op, kindMap); since the ctor has the op and is setting the builder ? But maybe that is too hidden and may not always be desired, so I am also OK with the explicit flag copy.
Thank you, Jean! Yes, I thought about automatically setting fastmath flags from the passed op, but it did not seem right to me. By definition, the passed op defines just the insertion point and does not necessarily refer to the operation that is being transformed. So there is a possibility that a pass transforms op1 with some fastmath flags, but uses op2 with other fastmath flags as an insertion point. I do not think it is possible now, but it may be the case later with MLIR-level inlining.