The constant folder for tosa.mul produces a tensor attribute whose type
may not match the result type of the operation when broadcasting is
needed. This results in a tosa.const op whose attribute's type does not
match the type of the const op.
This change explicitly expands the attribute to the expected result
type.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
We should not be folding if the type changes AFAIK (I think that may not be enforced ...). Is this change effectively ensuring it doesn't change types?
This change is ensuring that the attribute produced by folding tosa.mul has a type which matches the result type of the tosa.mul operation. The folder for tosa.mul was not broadcasting the resulting attribute when multiplying by zero. The resizeSplat is performing the required broadcast, in this case.
The IR operations are always well typed (input/output types), before and after folding, as far as I can tell. However, you end up with `tosa.const operations like this:
mlir %0 = "tosa.const"() {value = dense<0.000000e+00> : tensor<1x1xf32>} : () -> tensor<100x100xf32>
I raised a question about this on this discourse thread: https://discourse.llvm.org/t/correctness-properties-of-fold-methods/70564
The change to the tosa.const definition is just adding a sanity check that would have caught this issue earlier.
@jpienaar Would you mind submitting this change then, since I do not have commit privileges?
I thought I had accepted this already, but don't see it recorded. LGTM for the reasons described in the discourse thread.