TLDR: similar to OpAsm{Op,Dialect}Interface, OpAsm{Type,Attr}Interface is for pretty-printing ASM names/alias based on Type/Attribute.
Demo implementation in [mlir] Add OpAsmType/AttrInterface · ZenithalHourlyRate/llvm-project@c220063 · GitHub
Example
func.func @result_name_from_op_asm_type_interface() {
// CHECK: %op_asm_type_interface =
%0 = "test.default_result_name"() : () -> !test.op_asm_type_interface
return
}
Recap on OpAsm{Op,Dialect}Interface
struct OpAsmOpInterface {
void getAsmResultNames(...);
void getAsmBlockArgumentNames(...);
};
struct OpAsmDialectInterface {
AliasResult getAlias(Attribute attr, raw_ostream &os);
AliasResult getAlias(Type type, raw_ostream &os);
};
Dialect and Op all have their own ability to hook into AsmPrinter to get custom name/alias. Yet the default implementation is “owned” by the Op/Dialect such that outside user could not affect the behavior.
Proposed Change
struct OpAsmTypeInterface {
StringRef getAsmName();
};
struct OpAsmAttrInterface {
StringRef getAsmName();
};
// Default impl of OpAsmOpInterface use the Interface to generate name
// Default impl of OpAsmDialectInterface use the Interface to generate alias,
// if the Dialect owns the Type/Attr
Motivation
Op does not always recognize its operands/results/block arguments (from other Dialect), so it might be better to provide an interface for it to know how to generate name for them.
For example, for a generic op like func::FuncOp, we would want its argument to be meaningful instead of always being argX. With this change, we can get ASM output like the belowing (taken from bgv-to-lattigo: lower client-interface and plain op by ZenithalHourlyRate · Pull Request #1226 · google/heir · GitHub)
func.func @dot_product(
%evaluator: !evaluator,
%params: !params,
%encoder: !encoder,
%ct: !ct,
%ct_0: !ct) -> !ct
For Dialect, instead of TypeSwitch on Type/Attr in dialect implemenentaion for OpAsmDialectInterface (see heir/lib/Dialect/LWE/IR/LWEDialect.cpp at 276bc7c53ad9b074ad3b8dde2756b1980e4c2707 · google/heir · GitHub), we can directly define these names in .td together with the Type/Attr definition so it is more manageable.
Impact
This is opt-in as the user has to add the Interface to its own Type/Attr. User could also implement their own {Op,Dialect}Interface to avoid/extend the default impl behavior. Existing user/downstream will not see change if they did not encounter any Type/Attr with this interface.
Review
Cc @j2kun, @AlexanderViand-Intel and @asraa for downstream HEIR project. Cc @River707 @mehdi_amini for relevent commit history.
