This is an archive of the discontinued LLVM Phabricator instance.

[MLIR][TableGen] Automatic detection and elimination of redundant methods
ClosedPublic

Authored by jurahul on Sep 2 2020, 3:21 PM.

Details

Summary
  • Change OpClass new method addition to find and eliminate any existing methods that are made redundant by the newly added method, as well as detect if the newly added method will be redundant and return nullptr in that case.
  • To facilitate that, add the notion of resolved and unresolved parameters, where resolved parameters have each parameter type known, so that redundancy checks on methods with same name but different parameter types can be done.
  • Eliminate existing code to avoid adding conflicting/redundant build methods and rely on this new mechanism to eliminate conflicting build methods.

Fixes https://bugs.llvm.org/show_bug.cgi?id=47095

Diff Detail

Event Timeline

jurahul created this revision.Sep 2 2020, 3:21 PM
Herald added a project: Restricted Project. · View Herald Transcript
jurahul requested review of this revision.Sep 2 2020, 3:21 PM

Nice, looks like good reduction

mlir/include/mlir/TableGen/OpClass.h
57

Nit: Start with capital letter as start of a sentence.

57

Nit: either to the given raw_ostream, or to os (the latter already indicates an explicit parameter and so the given is redundant)

80

Prefer comment on line before parameter for uniformity.

84

Nit: K -> kind to avoid clang-tidy warning (especially if we move these again).

90

Same as above here and below.

109

update this too to follow naming convention (https://mlir.llvm.org/getting_started/DeveloperGuide/#style-guide)

190

Why is this one in the header file?

203

Doesn't cast assert too if not true?

237–241

I feel these top comments don't add anything to the enum name really and I'd be pro eliding them.

240

What does only provide here? E.g., if we had MP_Declaration instead is their ambiguity?

317

Does it get pruned or does it just not get added? Pruning for me implies it was already added.

321

So this adds if not redundant and prunes if this makes an existing one redundant? Struggling to capture that all in one name ... addIfNonRedundantAndMaybePrune doesn't roll off the tongue :) This is fine, unless you have a better idea.

376

Why not use setvector if the insertion ordering is required?

mlir/lib/TableGen/OpClass.cpp
84

How about using interleave method here?

mlir/test/mlir-tblgen/op-attribute.td
110

Is this change related?

jurahul updated this revision to Diff 292022.Sep 15 2020, 2:06 PM
jurahul marked 14 inline comments as done.

Review feedback

mlir/include/mlir/TableGen/OpClass.h
190

Moved it to cpp.

203

I think it does.

317

It could be implemented that way as well (just add and then prune all redundant). But I have clarified the comment to indicate that its either not added or added.

321

Yes, it's a one shot to preserve the invariant that there are no redundant methods at any point. To perfectly explain the functionality its addIfNotRedundant_Else_AddAndPruneRedundant(). I don't have a better idea. I was thinking addMethoAndPruneRedundant() but I don't think the extra redundant adds anything. I am open to suggestions if others have it.

376

SetVector of unique_ptr<>'s is not supported (results in compile time errors due to copy constructors used).

mlir/lib/TableGen/OpClass.cpp
84

interleave() operates on a container of items, so I saved the tokens into a vector so that I can use the interleave here.

mlir/test/mlir-tblgen/op-attribute.td
110

Yes. There is already another $type_attr here below, so the functions for this one were getting removed as the newly added code thinks they are redundant.

jurahul added inline comments.Sep 17 2020, 1:19 PM
mlir/include/mlir/TableGen/OpClass.h
376

I looked into this a bit more. SetVector maintains 2 copies of the elements in the set, one in a set and one in a vector for the insertion order. As a result unique_ptr<> cannot be held in a SetVector.

jpienaar accepted this revision.Sep 17 2020, 1:57 PM

LG, thanks

This revision is now accepted and ready to land.Sep 17 2020, 1:57 PM
This revision was landed with ongoing or failed builds.Sep 17 2020, 4:05 PM
This revision was automatically updated to reflect the committed changes.