This is an archive of the discontinued LLVM Phabricator instance.

[mlir] Allow to override type/attr aliases from various hooks
ClosedPublic

Authored by vinograd47 on Aug 4 2021, 2:42 AM.

Details

Summary

Use new return type for OpAsmDialectInterface::getAlias:

  • AliasResult::NoAlias if an alias was not provided.
  • AliasResult::OverridableAlias if an alias was provided, but it might be overriden by other hook.
  • AliasResult::FinalAlias if an alias was provided and it should be used (no other hooks will be checked).

In that case AsmPrinter will use either the first alias with FinalAlias result or
the last alias with OverridableAlias result (it depends on dialect array order).

Used OverridableAlias result for BuiltinOpAsmDialectInterface.

Use case: provide more informative alias for built-in attributes like AffineMapAttr
instead of generic "map<N>".

Diff Detail

Event Timeline

vinograd47 created this revision.Aug 4 2021, 2:42 AM
vinograd47 requested review of this revision.Aug 4 2021, 2:42 AM
rriddle requested changes to this revision.Aug 4 2021, 8:42 AM

If this is just to avoid the generic alias in the "parent" dialect (in this case, the builtin dialect), can we just flip the iteration order of the dialect interfaces when building the alias set? I'm not sure when Optional would ever really be used outside of that use case.

This revision now requires changes to proceed.Aug 4 2021, 8:42 AM

If this is just to avoid the generic alias in the "parent" dialect (in this case, the builtin dialect), can we just flip the iteration order of the dialect interfaces when building the alias set? I'm not sure when Optional would ever really be used outside of that use case.

The problem is, that the order of dialect interfaces depends on the order of dialects stored in MLIRContext object. The MLIRContext stores dialects in DenseMap<StringRef, std::unique_ptr<Dialect>> with dialect name as key. And it seems that the issue we faced was caused by adding explicit name (builtin) to BuiltinDialect (originally it has an empty name). I didn't find other way to somehow specify the order of alias checks.

Optional might be used for the cases, when some hook provides just general name per object type (like map or set) without extra information from the object properties (like special names for specific affine maps). For example, in our internal project we provide such Optional alias for quantized types from quant dialect, but allows to override this alias with more specific if needed.

If this is just to avoid the generic alias in the "parent" dialect (in this case, the builtin dialect), can we just flip the iteration order of the dialect interfaces when building the alias set? I'm not sure when Optional would ever really be used outside of that use case.

The problem is, that the order of dialect interfaces depends on the order of dialects stored in MLIRContext object. The MLIRContext stores dialects in DenseMap<StringRef, std::unique_ptr<Dialect>> with dialect name as key. And it seems that the issue we faced was caused by adding explicit name (builtin) to BuiltinDialect (originally it has an empty name). I didn't find other way to somehow specify the order of alias checks.

Optional might be used for the cases, when some hook provides just general name per object type (like map or set) without extra information from the object properties (like special names for specific affine maps). For example, in our internal project we provide such Optional alias for quantized types from quant dialect, but allows to override this alias with more specific if needed.

The second part makes sense.

mlir/include/mlir/IR/OpImplementation.h
931

What about OverridableAlias instead of OptionalAlias?

And, what about NoAlias as opposed to NotSupported? (It follows the tone of the others results more)

Also, can you document this enum?

mlir/lib/IR/AsmPrinter.cpp
657–659

nit: Spell out auto here.

658

nit: Drop the newline here.

663

nit: Drop the newline here.

mlir/test/lib/Dialect/Test/TestDialect.cpp
83

Can you use a test type instead of index? Less likely to cause a problem in other tests.

vinograd47 updated this revision to Diff 364717.Aug 6 2021, 1:04 AM
vinograd47 edited the summary of this revision. (Show Details)

Apply review remarks

vinograd47 marked 5 inline comments as done.Aug 6 2021, 1:06 AM

@rriddle I've applied your suggestions.

rriddle accepted this revision.Aug 6 2021, 1:23 AM

LG, thanks!

This revision is now accepted and ready to land.Aug 6 2021, 1:23 AM