This is an archive of the discontinued LLVM Phabricator instance.

[ADT] Add Compare template param to EquivalenceClasses
ClosedPublic

Authored by springerm on Oct 18 2021, 8:55 PM.

Details

Summary

This makes the class usable with types that do not provide their own operator<.

Update MLIR Linalg ComprehensiveBufferize to take advantage of the new template param.

Diff Detail

Event Timeline

springerm created this revision.Oct 18 2021, 8:55 PM
springerm requested review of this revision.Oct 18 2021, 8:55 PM
ftynse added inline comments.Oct 19 2021, 6:10 AM
llvm/include/llvm/ADT/EquivalenceClasses.h
105

It feels expensive to construct the comparator object on each call to operator<. Caching it in the ECValue isn't really a good option because it will consume a lot of space, even if we only keep a reference to the comparator stored in the EquivalenceClassses. Can't we just pass the template parameter down to std::set, potentially wrapped in some extra class? AFAIK, the set implementation will only keep one copy of the comparator.

address comments

springerm marked an inline comment as done.Oct 19 2021, 10:33 PM
springerm added inline comments.
llvm/include/llvm/ADT/EquivalenceClasses.h
105

Done.

I don't expect comparator classes to have state. So in most cases, I would not expect any overhead from instantiation. But you're right if the comparator happens to have state...

ftynse accepted this revision.Oct 20 2021, 2:54 AM

LGTM. Please double-check that all tests pass before landing, premerge checks report some failures.

This revision is now accepted and ready to land.Oct 20 2021, 2:54 AM
springerm marked an inline comment as done.

rebase

springerm updated this revision to Diff 383723.Nov 1 2021, 12:19 AM

maybe fix bug

This revision was automatically updated to reflect the committed changes.

Could you add some test coverage for the LLVM change in LLVM (an ADT unit test seems appropriate)?

Could you add some test coverage for the LLVM change in LLVM (an ADT unit test seems appropriate)?

Ping on this ^

Could you add some test coverage for the LLVM change in LLVM (an ADT unit test seems appropriate)?

Ping on this ^

Sorry, I missed your comment. Test case is here: D113461