[Mlir-commits] [mlir] [mlir][tosa] Add a pass to downgrade TOSA `1.1.draft` to `1.0` (PR #194971)

[Luke Hutton]

================
@@ -185,6 +185,17 @@ def TosaAttachTarget : Pass<"tosa-attach-target", "ModuleOp"> {
   ];
 }
 
+def TosaDowngrade1p1To1p0Pass
+    : Pass<"tosa-downgrade-1-1-to-1-0", "func::FuncOp"> {
+  let summary = "Downgrade TOSA 1.1 specification constructs to TOSA 1.0";
+  let description = [{
+    Rewrites constructs which are only compatible in TOSA specification 1.1 and
+    above to their TOSA 1.0 counterparts where possible. Downgrading is best-effort
+    and validation should be performed afterwards to ensure compatibility with
----------------
lhutton1 wrote:

Originally I had a version that did this, but decided against it for a few reasons:
- Deferring validation allows a user to use other passes to clean up the IR before trying to validate. For example they may choose to `--tosa-narrow-i64-to-i32` to remove dependence on a 1.1 extension. Enforcing validation forces the order which these passes can run which seems unfortunate.
- If no target_env has been provided, what should the pass do? Not run validation, or construct a new target_env with values like: `specification_version=1.0 profiles=<all-1.0-profiles> extensions=<all-1.0-extensions> ...` for validation to run?
- When downgrade passes are chained running validation on the provided target_env will be problematic. For example, say target_env is `specification_version=1.0` and we are downgrading from 1.2, running validation in the `--tosa-downgrade-1-2-to-1-1` pass would likely fail due to the target_env containing `specification_version=1.0`

.. hope this helps explain my thinking, happy to hear other thoughts here!

https://github.com/llvm/llvm-project/pull/194971