This is an archive of the discontinued LLVM Phabricator instance.

[mlir] Update `simplifyRegions` to use RewriterBase for erasure notifications
ClosedPublic

Authored by rriddle on Mar 16 2021, 6:14 PM.

Details

Summary

This allows for notifying callers when operations/blocks get erased, which is especially useful for the greedy pattern driver. The current greedy pattern driver "throws away" all information on constants in the operation folder because it doesn't know if they get erased or not. By passing in RewriterBase, we can directly track this and prevent the need for the pattern driver to rediscover all of the existing constants. In some situations this cuts the compile time of the canonicalizer in half.

Diff Detail

Event Timeline

rriddle created this revision.Mar 16 2021, 6:14 PM
rriddle requested review of this revision.Mar 16 2021, 6:14 PM
lattner accepted this revision.Mar 16 2021, 10:08 PM

Very nice. Question about this: how general is simplifyRegions actually? Should it be merged in as an implementation detail of Canonicalize, rather than a public interface in RegionUtils.h?

This revision is now accepted and ready to land.Mar 16 2021, 10:08 PM

Very nice. Question about this: how general is simplifyRegions actually? Should it be merged in as an implementation detail of Canonicalize, rather than a public interface in RegionUtils.h?

That is a good question. When I originally added this stuff, it seemed in the vein of what is in BasicBlockUtils. If we go along those lines, it would probably make sense to keep unreachable block elim generally available. Block merging and RegionDCE on the other hand are basically just implementation details of canonicalize already (nothing else calls simplifyRegions, at least upstream or within Google users). What do you think of that split? (i.e. keep unreachable block elim public, but move the rest to canonicalize).

I think the split is premature generalization in this case. The details of simplifyRegions are very specific -- an equivalent to BBUtils would be exposing the individual components (eraseUnreachableBlocks etc). Given that we don't have any additional clients for this (and it is about to get even more specific with RewriterBase) I'd just embrace that this is part of canonicalize. When/if another client comes around, we can refactor and publish it then

I think the split is premature generalization in this case. The details of simplifyRegions are very specific -- an equivalent to BBUtils would be exposing the individual components (eraseUnreachableBlocks etc). Given that we don't have any additional clients for this (and it is about to get even more specific with RewriterBase) I'd just embrace that this is part of canonicalize. When/if another client comes around, we can refactor and publish it then

SGTM. I was hesitant at first as things sometimes get lost when they are within random passes, but that probably isn't really relevant for something as prevalent as the canonicalizer.

makes sense. Things like eraseUnreachableBlocks are simple enough that it isn't the end of the world if they get duplicated.

makes sense. Things like eraseUnreachableBlocks are simple enough that it isn't the end of the world if they get duplicated.

Thanks for the discussion Chris! Moved in D98885.

Just recently in flang there was a pass reimplementing some local very simplified DCE and I was suggesting to either call simplifyRegions or add a new utils in MLIR for this.

The value of such utilities is to avoid client to reimplement over and over some version of the same algorithms, so I encourage providing these (and a home for more of these) in general!

The value of such utilities is to avoid client to reimplement over and over some version of the same algorithms, so I encourage providing these (and a home for more of these) in general!

Well sure, but there is a balance. In this case, we want to build on RewriterBase to make the specific use-case of canonicalize more efficient. This isn't something that a general DCE implementation would want to bother with (it will just slow it down and make it more complicated) so it really is specific to the canonicalize pass.

I still believe we should simplify the DCE algorithm here in general :)