[Mlir-commits] [mlir] [mlir][spirv][tosa] Add remaining TOSA 1.0 SPIR-V TOSA ops (PR #200383)
Luke Hutton
llvmlistbot at llvm.org
Fri May 29 06:10:04 PDT 2026
lhutton1 wrote:
I've not followed the TOSA -> SPIRV lowering much, so please bear with. Is the expectation that the TOSA -> SPIRV could receive an invalid TOSA graph which it then needs to manipulate to become valid TOSA according to the specification?
I think a better approach could be to expect the TOSA graph to have been validated for conformance to the specification, using e.g. `--tosa-validate`, before this lowering to SPIRV is invoked. This will reduce the need for duplicated transformation logic such as:
- I64 -> I32 conversion: https://github.com/llvm/llvm-project/pull/200383/changes#diff-21b05822f0b97d1ea268c66784b4bfdc94c356fedad885d9b15d1c298049920eR65 - in TOSA we have the `--tosa-narrow-i64-to-i32` pass to handle this
- Splitting concat: https://github.com/llvm/llvm-project/pull/200383/changes#diff-21b05822f0b97d1ea268c66784b4bfdc94c356fedad885d9b15d1c298049920eR95 - I appreciate there is no logic in the TOSA dialect yet to handle this case, but I think we should add it, perhaps under the `tosa-optional-decompositions` or as a separate pass. The tosa-converter-for-tflite project recently added similar logic (https://gitlab.arm.com/tosa/tosa-converter-for-tflite/-/merge_requests/90/diffs#5fa8bccb4d794980e8f604c7eab1979ae68d76c4_855_858), giving further motivation to consolidate into one place.
https://github.com/llvm/llvm-project/pull/200383
More information about the Mlir-commits
mailing list