This is an archive of the discontinued LLVM Phabricator instance.

[mlir] use storage uniquer for side effects
AbandonedPublic

Authored by ftynse on Sep 3 2020, 10:09 AM.

Details

Summary

The Effect class hierarchy in the side effect infrastructure currently only
supports non-parametric effects uniquely identified by their type. Only one
instance of each effect is stored in method and returned by-pointer upon
request. Hook the Effect class hierarchy to StorageUniquer instead. This makes
Effect and derived classes value-types, similarly to types and attributes, and
prepares the ground for parametric effets.

Diff Detail

Event Timeline

ftynse created this revision.Sep 3 2020, 10:09 AM
Herald added a project: Restricted Project. · View Herald TranscriptSep 3 2020, 10:09 AM
ftynse requested review of this revision.Sep 3 2020, 10:09 AM
mehdi_amini added inline comments.Sep 3 2020, 10:18 PM
mlir/lib/IR/MLIRContext.cpp
27

I don't really understand the layering here: I'm not convinced that the Context should be made aware of this?

ftynse added inline comments.Sep 4 2020, 12:37 AM
mlir/lib/IR/MLIRContext.cpp
27

I am not happy with this either, this wouldn't scale to user-defined side effects. The other things that have uniquers are organized as follows:

  • types and attributes are registered by the dialect;
  • affine constructs (arguably they are part of the IR, not dialect) are registered here.

Any suggestions? @rriddle ?

ftynse abandoned this revision.Nov 23 2020, 12:52 AM

Replaced with another approach - https://reviews.llvm.org/D91493.