This is an archive of the discontinued LLVM Phabricator instance.

Fold certain ops during dialect conversion
Needs ReviewPublic

Authored by bondhugula on Jan 5 2022, 6:55 AM.

Details

Summary

Ops like builtin.unrealized_cast are meant to be folded during dialect
conversion. Update dialect conversion driver to fold ops with trait
FoldOnDialectConversion irrespective of whether they are marked illegal.

This revision also moves the check on "ignored ops" to earlier which has
functionally no impact but potentially an efficiency win.

Diff Detail

Event Timeline

bondhugula created this revision.Jan 5 2022, 6:55 AM
bondhugula requested review of this revision.Jan 5 2022, 6:55 AM
bondhugula updated this revision to Diff 397560.Jan 5 2022, 7:03 AM

Tweak comment.

bondhugula updated this revision to Diff 397588.Jan 5 2022, 8:21 AM

Drop unrelated change.

IMO it would be better to have a way for the person specifying the conversion target to say "get rid of these ops if you can". Unrealized conversion cast is a bit of an odd duck, but it seems that "get rid of this during dialect conversion if possible" is more often a property of the conversion than a property of the op. I guess it could be either or both (where unrealized conversion is the relatively special case where it makes sense to have it on the op). It also feels like an arbitrary limitation that such an op can only be removed with folding and not with canonicalization or some other pattern.

it seems that "get rid of this during dialect conversion if possible" is more often a property of the conversion than a property of the op

That would be my feeling as well on this.

I guess it could be either or both (where unrealized conversion is the relatively special case where it makes sense to have it on the op). It also feels like an arbitrary limitation that such an op
can only be removed with folding and not with canonicalization or some other pattern.

Right - we may need both, i.e., special ops (with a specific trait) or ops that the user wants to remove. The latter would need a change to the API itself or a new "target" class like addLegalButOptimize which isn't the goal of this revision. Besides, if there is a use case to canonicalize and fold-out a specific set of ops or op types, you can always do that with another call to applyPatternsAndFoldGreedily or applyOpPatternsAndFold with just those ops' canonicalization patterns added. It's arguable as to whether you'd want dialect conversion to take on that concern. Separately, it's easy for me to make a change to run legalizeWithPattern as well on these FoldDuringDialectConversion ops so that you get both folding and canonicalization for them -- the trait will then have to be renamed SimplifyDuringDialectConversion.

Does this actually remove the need to run the reconciliation pass in our test suite?

Does this actually remove the need to run the reconciliation pass in our test suite?

I can check this but the goal is to remove the need to run this reconciliation for all downstream users as well -- I wouldn't want to merge this in otherwise. Besides LLVM, I can check IREE as well.