This is an archive of the discontinued LLVM Phabricator instance.

[flang] Initial support for FastMathAttr setup in FirOpBuilder.
ClosedPublic

Authored by vzakhari on Nov 3 2022, 11:40 PM.

Details

Summary

Provide FirOpBuilder::setFastMathFlags() to configure FastMathFlags
for the builder. Set FastMathAttr for operations based on FirOpBuilder
configuration via mlir::OpBuilder::Listener.

This is a little bit hacky solution, because we lose the ability
to hook other listeners to FirOpBuilder. There are also potential
issues with OpBuilder::clone() - the hook will be invoked for cloned
operations and will effectively overwrite FastMathAttr with the ones
configured in FirOpBuilder, which should not be happening.
We should teach mlir::OpBuilder about FastMathAttr setup in future.

Diff Detail

Event Timeline

vzakhari created this revision.Nov 3 2022, 11:40 PM
vzakhari requested review of this revision.Nov 3 2022, 11:40 PM
tblah added a subscriber: tblah.Nov 4 2022, 3:27 AM
jeanPerier added a comment.EditedNov 4 2022, 7:08 AM

This is a little bit hacky solution, because we lose the ability
to hook other listeners to FirOpBuilder. There are also potential
issues with OpBuilder::clone() - the hook will be invoked for cloned
operations and will effectively overwrite FastMathAttr with the ones
configured in FirOpBuilder, which should not be happening.
We should teach mlir::OpBuilder about FastMathAttr setup in future.

Do you see any solutions for the clone issue (i.e., would it be possible to remove the listener while cloning by implementing a clone override that remove itself as a listener, call the parent clone method, and adds itself back ? ) ?
Or do you think there would be other solutions to deal with the fastMathAttr setting without using a listener, but that would take much more effort at that stage ?

This is a little bit hacky solution, because we lose the ability
to hook other listeners to FirOpBuilder. There are also potential
issues with OpBuilder::clone() - the hook will be invoked for cloned
operations and will effectively overwrite FastMathAttr with the ones
configured in FirOpBuilder, which should not be happening.
We should teach mlir::OpBuilder about FastMathAttr setup in future.

Do you see any solutions for the clone issue (i.e., would it be possible to remove the listener while cloning by implementing a clone override that remove itself as a listener, call the parent clone method, and adds itself back ? ) ?
Or do you think there would be other solutions to deal with the fastMathAttr setting without using a listener, but that would take much more effort at that stage ?

i.e., would it be possible to remove the listener while cloning by implementing a clone override that remove itself as a listener, call the parent clone method, and adds itself back ?

This is a possibility, but unfortunately it will be unreliable as well. clone is not a virtual method of OpBuilder, so any redefinition that we add in FirOpBuilder will be only invoked if the method is invoked via an object with static FirOpBuilder type. If one does this via the base OpBuilder pointer our redefinition will be ignored.

I think the "default" attributes setup for new operations produced via OpBuilder should be a first class citizen of OpBuilder itself. Then we can define it as "set attributes defined by the current configuration of OpBuilder only for new instructions, i.e. methods that copy existing instructions (e.g. clone) just copy the instructions verbatim" - something along these lines. This requires some public discussion. I would like to proceed with this hacky approach so that we collect data about the issues along the road and sculpture the interfaces that we need to make this work for Flang. And in the meantime this allows us to have some support for fastmath, so that we can collect performance data showing the impact of proper fastmath handling. I am not sure if the clone issue in FirOpBuilder will affect Flang at all - I hope having this fastmath support will highlight cases where it may be an issue. When we have all things sorted out, we can specify what we need from OpBuilder.

tschuett added inline comments.
flang/include/flang/Optimizer/Builder/FIRBuilder.h
417

The virtual is not needed when you have override.

vzakhari updated this revision to Diff 473269.Nov 4 2022, 9:48 AM
vzakhari marked an inline comment as done.

LGTM. Please wait for @jeanPerier.

flang/include/flang/Optimizer/Builder/FIRBuilder.h
408

Would we need to change the fastmath setting in practice? As a design would it be good to not change the setting once a Builder is created?

flang/unittests/Optimizer/Builder/FIRBuilderTest.cpp
532

Nit: A one-line explanation before each case might be helpful. For e.g, I have give below an explanation for each case. Feel free to skip if it will be verbose.
-> Test that the fast-math flag setting is none by default.
-> Check that setting the fast-math flag is honoured while creating an operation and is not impacted by the setting on a copy.
-> Check the setting of fast-math flags on an operation created with a copied builder.
-> When FIROpbuilder is copied the fast-math flags are retained

This revision is now accepted and ready to land.Nov 4 2022, 10:12 AM
vzakhari added inline comments.Nov 4 2022, 10:20 AM
flang/include/flang/Optimizer/Builder/FIRBuilder.h
408

Yes, I think we may want to change it in some cases. I tried to come up with some examples in https://discourse.llvm.org/t/attaching-arith-fastmathattr-to-operations-in-flang/66366. Maybe they are not quite robust, but I would like to keep this possibility. FWIW, llvm::IRBuilderBase supports changing fastmath settings (and it is used) along with helper guards to revert to the previous state after local flags override.

flang/unittests/Optimizer/Builder/FIRBuilderTest.cpp
532

Sure! Will do.

vzakhari updated this revision to Diff 473296.Nov 4 2022, 10:58 AM

Added comments in the test.

jeanPerier accepted this revision.Nov 7 2022, 12:47 AM
vzakhari marked an inline comment as done.Nov 7 2022, 8:39 AM

Thank you for the review, Kiran and Jean!