With this extension, shall an Op be able to accept non-constant tensors for the original compile-time constants? Or does it still only accept constant Ops, and we just not attempt to get the values until runtime?
For example, the “shift” in TOSA::MulOP. In the current tosa::MulOp::verify() function and TosaToLinalg pass, it’s only expecting constants. It fails if I pass a non-constant tensor as the shift. Is this an expected behavior?
The default behavior i to have it be CTC, with EXT-DYNAMIC intending to loosen that. If I understood right, it sounds like the verifier is not able to accommodate the loosening of semantics under EXT_DYNAMIC.If so, please feel free to submit an issue on llvm-project for this. You can assign or mention me to begin with.
With this extension, shall an Op be able to accept non-constant tensors for the original compile-time constants?
This is correct.
I suspect the failure is due to lack of support in the TosaToLinalg lowering for MUL with non-const inputs e.g. llvm-project/mlir/lib/Conversion/TosaToLinalg/TosaToLinalg.cpp at main · llvm/llvm-project · GitHub. In a sense, TosaToLinalg does not yet implement/support the EXT-DYNAMIC extension.
As a side note, the verify functions should allow either const/non-const tensors, it’s the job of the tosa-validate pass to catch misuse, depending on whether support for the EXT-DYNAMIC extension is declared or not. I see the validate pass is run in the TosaToLinalg pipeline, but currently without the “strict-op-spec-alignment” option, meaning CTC conformance won’t currently get checked, hence the issue being caught in the lowering to linalg. Perhaps we can consider having CTC checking without requiring the “strict-op-spec-alignment” option to catch misuse earlier (with the benefit of a clearer error message)?
Thanks for the clearifications.
The failure I got was from the TosaToLinalg pass, where it only expects constants at the moment. And yes, there’s no checking in the Op varifications for CTC.