Did I find a bug? Converting TOSA to LinAlg

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:

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!

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

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.

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

@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.

@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

@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:

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

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.


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