In D151117#4375142, @mehdi_amini wrote:

to have a working legalization to linalg.

Is there a path from there to linalg? It's not clear to me how it works?
And actually I'm wondering if this lowering could be expressed with a linalg.generic indeed?

Thanks for taking this on. Scatter is a complicated op, and it is good to have a working legalization to linalg.

Seems reasonable. It's a fairly complex legalization, but necessary. Thanks for adding this.

Looks good, thanks for the fix.

I think the issue is that floor/ceil/clamp don't have the SameOperandsAndResultType trait which is required by the Idempotent trait. It should be okay to add for floor/ceil/clamp as they shouldn't change type.

Looks good, matches what is in the TOSA specification.

Looks good to me.

One minor change, otherwise it looks good to me.

Thanks! LGTM now. Let me know if you need help landing this.

I should be able to help land it, hopefully tomorrow.

Looks good to me.

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

Thanks for the ping, this got lost in my todo list.

This seems like a reasonable fold to me, and a good heuristic to start with. Adding @jpienaar in case he sees anything I've missed.

Agreed that this looks good, with only changes in the description that seem to be needed. As mentioned inline, part of the blame lies on the spec, and I'm going to try to correct the spec to allow legalizations to choose the best option, listing the existing version as an option rather than appearing to be required. (Let me know if there is benefit to the spec as is)

LGTM.

LGTM.

LGTM.

looks good to me.

LGTM.

In D148498#4282904, @AviadCo wrote:

Well, removing new_shape is a big refactor which I think reuqires propare discussion if we would like to do so.
I also agree with @jpienaar's comment, but until we decide otherwise I think that infer shape can be useful and missing functionality to check element type of TOSA reshape operation.
We can raise a discussion to get ride of new_shape attribute and part of the work will be to revert this change.

In D148296#4270000, @mehdi_amini wrote:

Yes this was somehow intentional: in the spirit of matching the minimum amount of information.
Best would be to use something like CHECK: tosa.cont followed by CHECK-SAME: value = 1

Thanks for adding this Mehdi.

Looks good to me.

Thanks for making all of the changes. Issue if you want to follow along: https://github.com/llvm/llvm-project/issues/61822. Not assigned to me, but if you're not working on it I'm less worried that someone else will pick it up without me knowing.

Good catch @mgehre-amd. I had been thinking along a similar path to what you described, your comment helped solidify my thoughts.
If we track fixing the verifier, then agree that we can drop the check here. In terms of this change, we should change the tests so that if we fix the verifier, we don't then have to change these tests. (We're likely to find other tests that fail, but let's make our future work easier 😄 ). While doing that, changing the commit message to drop the mention of lower dimension helps avoid confusion.

In D145738#4228947, @sjw36 wrote:

@eric-k256 thanks. I didn't see a hard requirement in the spec and was confused by the test above for add_zero_different_shape. Also turns out there is a AddZeroOptimization and MulOneOptimization that also allow mixed rank folding.. also kind of redundant. Shall I remove those as well?

I like the cleanup and the overall simplification of the code, but the broadcast issue still remains. Not specifically called out, but in addition to the marked issues, updating the commit message would also be good.

Looks good to me. Thanks.

Adding @rsuderman, the author of the existing fold code as a more appropriate reviewer.

Added Rob as an additional reviewer. As mentioned, this matches with the TOSA specification, and looks like a nice simplification at the same time.

Given Rob's comments, I think that the path forward is to get comments from a wider set of people about making the switch to signed/unsigned from signless/signed so we aren't surprising any TOSA dialect users when we get to the point of removing signless support. An RFC on discourse seems to be the right way to do that, along with some time to collect responses. All of the lit tests are going to need to change, which is going to be a big set of changes that need to land. Most of it is mechanical, but still a lot of overhead.

As noted in the thread, I want to make sure that we're moving to remove i8 support in the near future, not supporting i8/ui8/si8. As a starting point to the move of i8 -> si8, this change is fine (mod Rob's comment), but it is starting down a path where multiple projects will be affected.

Thanks for checking Rob. Yes, this looks good to me.

You're right that F64 isn't in any of the TOSA profiles today, which is why I was discouraging it's use in the overall definition of Tosa_Tensor. It's something we look at adding, but it adds significant requirements to any profiles it goes into. It would be good to get a sense of what networks need F64 vs ending up with that type as default. Many systems that support f64 do it at a performance cost against f32, and some systems don't implement it at all. Ideally the tooling would have a way to guide developers to minimize their use of f64 to where it has a significant improvement on results justifying the extra computation cost.

Looks reasonable to me, although I don't have merge priveleges.

This is definitely an improvement, I'm okay with this type, but it reads as only a 64-bit tensor. Perhaps Jacques is better at naming than I am, but I'd go something closer to Tosa_Tensor_Plus_F64, indicating that this is an extension of Tosa_Tensor with F64 (as opposed to I64).

I don't have commit privileges. @rsuderman or @NatashaKnk, can you take a look?

While waiting for the others to review, you might want to remove the extra include.

Thanks. Looks good to me now.

Can you add a simple check to TosaValidation::runOnOperation that goes into the existing for loop and checks for float64 type, and does a signalPassFailure there? You don't need to check profileType, as f64 isn't in the spec. This pass is for implementations to use to check against the spec, so dialect specific changes that aren't in the spec should be flagged when it is run.

The TOSA specification doesn't support F64, so I think we should be careful in how we expand the data types in the dialect. Adding it has implications for TOSA consumers.

Decisions on what can be fused are often very hardware specific. I do like that the partitioning is parameterized, so that if I'm understanding properly, any set of ops can be defined as anchor as well as leading/trailing ops to be captured. Is a new function the right destination for these? Have you looked at using the ml_program dialect to capture this as a region? I would imagine the overall structure wouldn't need to change significantly. It's at least an option worth considering.

This looks nice. Is there something needed before this can be merged? Presumably any user of the tosa dialect that has lit tests would also need their tests to be modified.

Rebased change

Yes, help landing would be appreciated.

It looks good to me, although I don't have commit rights, so it might not be all the approvals you need.

I didn't find any uses of ReluN downstream, it must have been cleaned up already.

This doesn't directly impact this change, but in the TOSA specification, we've removed the ReluN operator, since it's trivially implementable with Clamp. I will look at removing ReluN from the dialect to line up with the specification.

Fix padding in the DecomposeTransposeConv passes to be compatible with the new attribute.
Added a testcase to try to catch future problems with padded transpose_conv.

Fix clang-format issue (clang-format 11 vs. clang-format 10 difference)

Thanks for doing this, I think it's the right solution.

Thanks for the clarification and comment.

In D105845#2883409, @jpienaar wrote:

I don't know the ops that well, I could verify these if interested, but was going to rely on Suraj else :)