Did I find a bug? Converting TOSA to LinAlg

MLIR
1

Hey! First time posting here.
I try to convert from tosa dialect to linalg, but I keep getting some weird error. If I use
mlir-opt -tosa-to-linalg-on-tensors tosanew.mlir > linalglowering.mlir
I get the expected error because the tf dialect is not milir native:
tosanew.mlir:37:11: error: ‘tf.Sign’ op created with unregistered dialect. If this is intended, please call allowUnregisteredDialects() on the MLIRContext, or use -allow-unregistered-dialect with mlir-opt

%34 = “tf.Sign”(%33) {device = “”} : (tensor<3x3x1x32xf32>) → tensor<3x3x1x32xf32>

^

tosanew.mlir:37:11: note: see current operation: %34 = “tf.Sign”(%33) {device = “”} : (tensor<3x3x1x32xf32>) → tensor<3x3x1x32xf32>
but if I use
mlir-opt -allow-unregistered-dialect -tosa-to-linalg-on-tensors tosanew.mlir > linalglowering.mlir
the task does not work at all. I get:

image
image2458×140 81.8 KB

It seems to fail on the very first line. Do I do something wrong or did I discover a bug?

For context: I used the tf compiler to lower from the tf dialect to the tosa dialect. Now I want to lower this to linalg and then after that to affine. Thanks for your help!

2

Adding @rsuderman here for confirmation, but I think tosa.const() gets processed to the Standard dialect’s std.constant by --tosa-to-standard .

3

This does seem to be the case. Maybe the tosa-to-linalg pass should not applyFullConversion if it is not handling all the TOSA ops.

4

If someone could point me in the right direction, I can try to fix it :slight_smile: If I understand you correctly you think it is a bug, too

5

@mbartel - We legalize tosa.const to std.const visa the TosaToStandard pass, so if you change your invocation to:

mlir-opt -allow-unregistered-dialect -tosa-to-standard -tosa-to-linalg-on-tensors tosanew.mlir > linalglowering.mlir

it should convert the tosa.const operation before hand. The tosa-to-linalg-on-tensors lowering is failing because it assumes that tosa-to-standard has already been invoked.

@MaheshRavishankar I am currently using the FullConversion so that we fail on unrecognized tosa operations so that we can guarantee everything is converted. Likely we will change back to a partial conversion once TOSA is complete. Overall I would like to have a single pipeline added to tosa-to-linalg instead of people invoking the pass themselves.

6

@mbartel Looking through the current tosa-to-linalg-on-tensors this should not occur as the pass specifically marks tosa.const as legal during the full conversion. Are you using an up to date version of mlir-opt? Can you send the input IR you are using?

1 Like
7

@rsuderman After some investigation the error was because of my M1 Mac. Everything works fine except for this weird case. I switched to an ubuntu server and it works.

However now I get an error regarding pooling:

image
image2850×194 106 KB

It is weird because if I look at the source code it looks ok…
Thank you for your help! This community is very nice :slight_smile:

1 Like
8

Cool, I can help from here as well. We are still working on statically shaped ops right now and haven’t begun on dynamic shapes (see the ? size). Its on a roadmap but you will need to guarantee your model is statically shaped for now.

Fortunately in a few weeks we should have tooling to shape propagate, which means if inputs are statically shaped, TOSA operations can propagate their shapes forward.

4 Likes
9

Thank you very much, you were very helpful!

Is there a way to help out a bit? I am still very new to MLIR but with a little bit of guidance I could help a little bit :slight_smile:

1 Like