This is an archive of the discontinued LLVM Phabricator instance.

[mlir] Add eraseOp method to OpBuilder.
AbandonedPublic

Authored by mravishankar on Nov 9 2020, 1:21 PM.

Details

Reviewers
rriddle
Summary

Depends On D90579

Diff Detail

Event Timeline

mravishankar created this revision.Nov 9 2020, 1:21 PM
Herald added a project: Restricted Project. · View Herald Transcript
mravishankar requested review of this revision.Nov 9 2020, 1:21 PM

I'm assuming the intent here is to allow for reusing the same bit of functionality from both pattern and non-pattern code? This is not the direction that I intended to move things given that I think it starts pushing OpBuilder further and further away from what it is intended to focus on(building IR). The direction I have intended to move to solve this problem is to evolve the PatternRewriter class into a more general OpRewriter class. The only method on PatternRewriter that is specific to patterns is notifyMatchFailure, but I think we could rename that to notifyRewriteFailure and it still works as a general concept. (At least, it looked fine in my WIP revision that does this, which I had intended to start pushing on soon). Thoughts on that direction?

mlir/include/mlir/IR/Builders.h
207

As an aside, a lot of work was done to make sure that OpBuilder does not have a vtable. Virtual hooks are added to the Listener class instead.

I'm assuming the intent here is to allow for reusing the same bit of functionality from both pattern and non-pattern code? This is not the direction that I intended to move things given that I think it starts pushing OpBuilder further and further away from what it is intended to focus on(building IR). The direction I have intended to move to solve this problem is to evolve the PatternRewriter class into a more general OpRewriter class. The only method on PatternRewriter that is specific to patterns is notifyMatchFailure, but I think we could rename that to notifyRewriteFailure and it still works as a general concept. (At least, it looked fine in my WIP revision that does this, which I had intended to start pushing on soon). Thoughts on that direction?

Sorry I missed this comments (on my phab dashboard it only shows up as requires me to respond when "changes are requested"). The reason I added this was that there might be utility functions that are doing transformations but are not using the pattern rewrite mechanism. The changes dependent on this change are an example of that. To summarize, I have a sequence of operations that need to be "modified". It is actually not easy to write this as a pattern for multiple reasons. So I am writing this as just an IR transformation. In IREE we have encountered this before where we have a transformation that is not written as a pattern rewrite. So there we have had to work around cases where there is a necessary utility function in PatternRewriter but not OpBuilder.
I dont have any strong opinions on how to proceed here, but I need the utility method that is doing transformation to accept a builder, i.e. one of OpBuilder or PatternRewriter. I dont think I can instantiate a pattern rewriter outside of the the GreedyPatternRewriter right?

mravishankar abandoned this revision.Nov 13 2020, 12:45 PM

I refactored my dependent changes to not require this patch. So abandoning this for now. Would be good to resolve this though.