Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

[mlir][MLProgram][NFC] Migrate to OpAsmAttrInterface for ASM alias generation #130481

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

ZenithalHourlyRate
Copy link
Member

After the introduction of OpAsmAttrInterface, it is favorable to migrate code using OpAsmDialectInterface for ASM alias generation, which lives in Dialect.cpp, to use OpAsmAttrInterface, which lives in Attrs.td. In this way, attribute behavior is placed near its tablegen definition and people won't need to go through other files to know what other (unexpected) hooks comes into play.

See #124721 for the interface itself and #128191 and #130479 for prior migrations.

Note that MLProgramOpAsmInterface has no content now. However, if we delete it, a failure related to dialect resource handling will occur

within split at llvm-project/mlir/test/IR/invalid-file-metadata.mlir:60 offset :7:7: error: unexpected error: unexpected 'resource' section for dialect 'ml_program'

To support resource such interface must be registered.

@llvmbot
Copy link
Member

llvmbot commented Mar 9, 2025

@llvm/pr-subscribers-mlir

Author: Hongren Zheng (ZenithalHourlyRate)

Changes

After the introduction of OpAsmAttrInterface, it is favorable to migrate code using OpAsmDialectInterface for ASM alias generation, which lives in Dialect.cpp, to use OpAsmAttrInterface, which lives in Attrs.td. In this way, attribute behavior is placed near its tablegen definition and people won't need to go through other files to know what other (unexpected) hooks comes into play.

See #124721 for the interface itself and #128191 and #130479 for prior migrations.

Note that MLProgramOpAsmInterface has no content now. However, if we delete it, a failure related to dialect resource handling will occur

within split at llvm-project/mlir/test/IR/invalid-file-metadata.mlir:60 offset :7:7: error: unexpected error: unexpected 'resource' section for dialect 'ml_program'

To support resource such interface must be registered.


Full diff: https://github.com/llvm/llvm-project/pull/130481.diff

2 Files Affected:

  • (modified) mlir/include/mlir/Dialect/MLProgram/IR/MLProgramAttributes.td (+13-1)
  • (modified) mlir/lib/Dialect/MLProgram/IR/MLProgramDialect.cpp (-8)
diff --git a/mlir/include/mlir/Dialect/MLProgram/IR/MLProgramAttributes.td b/mlir/include/mlir/Dialect/MLProgram/IR/MLProgramAttributes.td
index eb6e293bbf4f6..2dc5727060064 100644
--- a/mlir/include/mlir/Dialect/MLProgram/IR/MLProgramAttributes.td
+++ b/mlir/include/mlir/Dialect/MLProgram/IR/MLProgramAttributes.td
@@ -11,6 +11,7 @@
 
 include "mlir/IR/AttrTypeBase.td"
 include "mlir/IR/BuiltinAttributeInterfaces.td"
+include "mlir/IR/OpAsmInterface.td"
 include "mlir/Dialect/MLProgram/IR/MLProgramBase.td"
 
 // Base class for MLProgram dialect attributes.
@@ -23,7 +24,7 @@ class MLProgram_Attr<string name, list<Trait> traits = []>
 // ExternAttr
 //===----------------------------------------------------------------------===//
 
-def MLProgram_ExternAttr : MLProgram_Attr<"Extern", [TypedAttrInterface]> {
+def MLProgram_ExternAttr : MLProgram_Attr<"Extern", [TypedAttrInterface, OpAsmAttrInterface]> {
   let summary = "Value used for a global signalling external resolution";
   let description = [{
   When used as the value for a GlobalOp, this indicates that the actual
@@ -40,6 +41,17 @@ def MLProgram_ExternAttr : MLProgram_Attr<"Extern", [TypedAttrInterface]> {
   let parameters = (ins AttributeSelfTypeParameter<"">:$type);
   let mnemonic = "extern";
   let assemblyFormat = "";
+
+  let extraClassDeclaration = [{
+    //===------------------------------------------------------------------===//
+    // OpAsmAttrInterface Methods
+    //===------------------------------------------------------------------===//
+
+    ::mlir::OpAsmAliasResult getAlias(::llvm::raw_ostream &os) const {
+      os << "}] # mnemonic # [{";
+      return ::mlir::OpAsmAliasResult::OverridableAlias;
+    }
+  }];
 }
 
 #endif // MLPROGRAM_ATTRIBUTES
diff --git a/mlir/lib/Dialect/MLProgram/IR/MLProgramDialect.cpp b/mlir/lib/Dialect/MLProgram/IR/MLProgramDialect.cpp
index bda1032ed9884..0b1561213165b 100644
--- a/mlir/lib/Dialect/MLProgram/IR/MLProgramDialect.cpp
+++ b/mlir/lib/Dialect/MLProgram/IR/MLProgramDialect.cpp
@@ -39,14 +39,6 @@ struct MLProgramInlinerInterface : public DialectInlinerInterface {
 
 struct MLProgramOpAsmDialectInterface : public OpAsmDialectInterface {
   using OpAsmDialectInterface::OpAsmDialectInterface;
-
-  AliasResult getAlias(Attribute attr, raw_ostream &os) const override {
-    if (llvm::isa<ExternAttr>(attr)) {
-      os << "extern";
-      return AliasResult::OverridableAlias;
-    }
-    return AliasResult::NoAlias;
-  }
 };
 } // namespace
 

@llvmbot
Copy link
Member

llvmbot commented Mar 9, 2025

@llvm/pr-subscribers-mlir-mlprogram

Author: Hongren Zheng (ZenithalHourlyRate)

Changes

After the introduction of OpAsmAttrInterface, it is favorable to migrate code using OpAsmDialectInterface for ASM alias generation, which lives in Dialect.cpp, to use OpAsmAttrInterface, which lives in Attrs.td. In this way, attribute behavior is placed near its tablegen definition and people won't need to go through other files to know what other (unexpected) hooks comes into play.

See #124721 for the interface itself and #128191 and #130479 for prior migrations.

Note that MLProgramOpAsmInterface has no content now. However, if we delete it, a failure related to dialect resource handling will occur

within split at llvm-project/mlir/test/IR/invalid-file-metadata.mlir:60 offset :7:7: error: unexpected error: unexpected 'resource' section for dialect 'ml_program'

To support resource such interface must be registered.


Full diff: https://github.com/llvm/llvm-project/pull/130481.diff

2 Files Affected:

  • (modified) mlir/include/mlir/Dialect/MLProgram/IR/MLProgramAttributes.td (+13-1)
  • (modified) mlir/lib/Dialect/MLProgram/IR/MLProgramDialect.cpp (-8)
diff --git a/mlir/include/mlir/Dialect/MLProgram/IR/MLProgramAttributes.td b/mlir/include/mlir/Dialect/MLProgram/IR/MLProgramAttributes.td
index eb6e293bbf4f6..2dc5727060064 100644
--- a/mlir/include/mlir/Dialect/MLProgram/IR/MLProgramAttributes.td
+++ b/mlir/include/mlir/Dialect/MLProgram/IR/MLProgramAttributes.td
@@ -11,6 +11,7 @@
 
 include "mlir/IR/AttrTypeBase.td"
 include "mlir/IR/BuiltinAttributeInterfaces.td"
+include "mlir/IR/OpAsmInterface.td"
 include "mlir/Dialect/MLProgram/IR/MLProgramBase.td"
 
 // Base class for MLProgram dialect attributes.
@@ -23,7 +24,7 @@ class MLProgram_Attr<string name, list<Trait> traits = []>
 // ExternAttr
 //===----------------------------------------------------------------------===//
 
-def MLProgram_ExternAttr : MLProgram_Attr<"Extern", [TypedAttrInterface]> {
+def MLProgram_ExternAttr : MLProgram_Attr<"Extern", [TypedAttrInterface, OpAsmAttrInterface]> {
   let summary = "Value used for a global signalling external resolution";
   let description = [{
   When used as the value for a GlobalOp, this indicates that the actual
@@ -40,6 +41,17 @@ def MLProgram_ExternAttr : MLProgram_Attr<"Extern", [TypedAttrInterface]> {
   let parameters = (ins AttributeSelfTypeParameter<"">:$type);
   let mnemonic = "extern";
   let assemblyFormat = "";
+
+  let extraClassDeclaration = [{
+    //===------------------------------------------------------------------===//
+    // OpAsmAttrInterface Methods
+    //===------------------------------------------------------------------===//
+
+    ::mlir::OpAsmAliasResult getAlias(::llvm::raw_ostream &os) const {
+      os << "}] # mnemonic # [{";
+      return ::mlir::OpAsmAliasResult::OverridableAlias;
+    }
+  }];
 }
 
 #endif // MLPROGRAM_ATTRIBUTES
diff --git a/mlir/lib/Dialect/MLProgram/IR/MLProgramDialect.cpp b/mlir/lib/Dialect/MLProgram/IR/MLProgramDialect.cpp
index bda1032ed9884..0b1561213165b 100644
--- a/mlir/lib/Dialect/MLProgram/IR/MLProgramDialect.cpp
+++ b/mlir/lib/Dialect/MLProgram/IR/MLProgramDialect.cpp
@@ -39,14 +39,6 @@ struct MLProgramInlinerInterface : public DialectInlinerInterface {
 
 struct MLProgramOpAsmDialectInterface : public OpAsmDialectInterface {
   using OpAsmDialectInterface::OpAsmDialectInterface;
-
-  AliasResult getAlias(Attribute attr, raw_ostream &os) const override {
-    if (llvm::isa<ExternAttr>(attr)) {
-      os << "extern";
-      return AliasResult::OverridableAlias;
-    }
-    return AliasResult::NoAlias;
-  }
 };
 } // namespace
 

ZenithalHourlyRate added a commit that referenced this pull request May 10, 2025
…face (#131504)

Since the introduction of `OpAsm{Type,Attr}Interface` (#121187), it is
possible to generate alias in AsmPrinter solely from the type/attribute
itself without consulting the `OpAsmDialectInterface`. This means the
behavior can be put in tablegen file near the type/attribute definition.

A common pattern is to just use the type/attr mnemonic as the alias.
Previously, like #130479/#130481/#130483, this means adding a default
implementation to `extraClassDeclaration` in `LLVM_Attr` base class.
However, as attribute definition may override `extraClassDeclaration`,
it might be preferred to have a new field in tablegen to specify this
behavior.

This commit adds a `genMnemonicAlias` field to `AttrOrTypeDef`, when
enabled, makes `mlir-tblgen` emit a default implementation of `getAlias`
using mnemonic. When `OpAsm{Attr,Type}Interface` is not specified by the
user, `tblgen` will automatically add the interface.

For users wanting other alias behavior, they can ignore such field and
still use `extraClassDeclaration` way.
@ZenithalHourlyRate ZenithalHourlyRate merged commit d102e90 into llvm:main May 12, 2025
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.