This is an archive of the discontinued LLVM Phabricator instance.

[mlir][tosa] Fix constant folding of tosa.mul
ClosedPublic

Authored by sabauma on May 12 2023, 4:48 AM.

Details

Summary

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.

Diff Detail

Event Timeline

sabauma created this revision.May 12 2023, 4:48 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 12 2023, 4:48 AM
sabauma updated this revision to Diff 521621.May 12 2023, 5:47 AM

Add verification check on the structure of tosa.const

sabauma published this revision for review.May 12 2023, 6:09 AM

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?

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 accepted this revision.May 16 2023, 8:12 AM
This revision is now accepted and ready to land.May 16 2023, 8:12 AM

@jpienaar Would you mind submitting this change then, since I do not have commit privileges?

eric-k256 accepted this revision.May 16 2023, 1:42 PM

I thought I had accepted this already, but don't see it recorded. LGTM for the reasons described in the discourse thread.

This revision was automatically updated to reflect the committed changes.