This is an archive of the discontinued LLVM Phabricator instance.

[mlir][linalg][bufferize][NFC] Simplify getAliasingOpOperand signature
ClosedPublic

Authored by springerm on Oct 1 2021, 7:29 PM.

Diff Detail

Event Timeline

springerm created this revision.Oct 1 2021, 7:29 PM
springerm requested review of this revision.Oct 1 2021, 7:29 PM
Herald added a project: Restricted Project. · View Herald TranscriptOct 1 2021, 7:29 PM

I am not sure why this is desirable?
I expect the ternary state to be useful in the future: None should be the catchall case that makes copies of everything it needs to.

springerm added a comment.EditedOct 6 2021, 10:57 PM

I am not sure why this is desirable?
I expect the ternary state to be useful in the future: None should be the catchall case that makes copies of everything it needs to.

My reasoning was that ops that we don't know about do not have an aliasingOpOperand. Therefore, nullptr is a valid return value. (Judging just from the function name, without reading the comment.) We would call hasKnownBufferizationAliasBehavior first when the op may be an unknown one. (It is not always the case.) This would make getAliasingOpOperand symmetrical to getAliasingOpResult, which also does no longer return Optional<>.

I am still on the fence about this one.
Note that in the other bigger CL, I point thatwe should prob. move to returning a list now.
Can we make that API change (which may also impact getAliasingOpResult) and see where we stand once it is in?

No need to support any new case, we would just bail on any list of size != 1 for now.

springerm updated this revision to Diff 378546.Oct 10 2021, 6:51 PM

address comments

nicolasvasilache accepted this revision.Oct 12 2021, 7:45 AM
This revision is now accepted and ready to land.Oct 12 2021, 7:45 AM
This revision was landed with ongoing or failed builds.Oct 12 2021, 5:48 PM
This revision was automatically updated to reflect the committed changes.