[Mlir-commits] [mlir] [mlir][tosa] Disallow inferable dim in reshape/slice validation (PR #182472)

[Luke Hutton]

================

----------------
lhutton1 wrote:

Yep this change is only intended for the validation pass when the "strict-op-spec-alignment" option is enabled, for now. So if you aren't using it, there should be no breaking change.

In general the dialect can represent a superset of the behaviour imposed by the specification. The `tosa-validate` pass is really intended to check conformance of a given IR to the specification. Any failure indicated by the validation pass is intended to highlight an unsupported lowering based on your hardware target (e.g. use of a bf16 operation when your hardware doesn't support it). It could also indicate a problem with a lowering pipeline (e.g. shape resolution is needed to convert a dynamic network to static for TOSA 1.0).

Today the validation pass can be used in a number of ways:
- `--tosa-validate="strict-op-spec-alignment"` - Checks strict compliance to the spec e.g. operations conform to specified profiles/extensions, check limitations imposed by the spec. Useful for tools that rely only on specification defined behaviour e.g. the reference model in [tosa-tools](https://gitlab.arm.com/tosa/tosa-tools) would not be able to interpret a value of -1.
- `--tosa-validate` - Checks for use of unsupported data-types, operations that exceed a specified target level, constant operand checks, invalid operation operand/result data types do not exist in the spec. Relaxed mode for legalizations from the dialect e.g. TosaToLinalg.
- `--tosa-validate="allow-invalid-op-datatype-combinations"` - Relaxes op datatype checks to the specification. E.g. it means a matmul op with an i8 input, but i16 accumulator type can be used.

My personal thoughts are that the validation pass should be stricter by default, e.g. the "strict-op-spec-alignment" option should only be reserved for any odd limitations the specification imposes while tosa-validate should do profile/extension checks by default. This would allow legalizations from TOSA to declare what lowerings they support based on the profiles/extensions they check for. However, changing this behaviour in the short-term is likely to be quite disruptive.

Hope this helps!

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