Does not that mean that in this example we yield values of different sizes on every iteration? I thought that type(iter_arg), type(result) and the type in scf.yield should all be compatible.

Is there an example of such scf.for? Maybe there is another way to fix it.

Thank you!

Address the comments.

Clean-up

address comments

Address the comments.

Thanks!

Address the comments.

update the test.

Is it equivalent to mlir-print-ir-after=pass-name ? https://mlir.llvm.org/docs/PassManagement/#ir-printing

Update

Add a test.

In D144450#4142321, @PeteSteinfeld wrote:

@pifon2a, this change broke the flang build. Can you please fix it sooner?

I used

Update tests

rebase

remove logging

Update.

Introduce mixed form.

"Is anybody out there?"

Revert unchanged file.

Reconsidered :)

Update.

In D144072#4128191, @chelini wrote:

Would it make sense to split this PR into two: rename and addition of step/lb/ub?

Rebase

Thank you!

In D142557#4083304, @mravishankar wrote:

I think the core logic being fixed here is not something I worked on, so I dont have full context. Adding folks who worked on this as reviewers...

For instance developers often store models/IR in linalg format to be able to work in isolation of the front end. Those kind of changes forces them to regenerate models.

So, it looks like launching a sed command is churn. Comments are not churn, even though they take much more time and effort.

Interesting, and in this case we cannot infer the result type based on operands? Isn’t the result type always matching the outs tensors?

I think Mehdi has a good point about spending more time on design. I agree clean ups are nice, however I feel like the incremental breaking changes are causing the problem and we shouldn’t take those lightly. I believe there has been several syntax changes proposed to linalg ops in the recent past? Should we make sure we have a syntax that won’t need more change in the near future before make those changes? (Maybe it is worth a quick chat on discourse to make sure we address all the potential syntax problems at once and not continuously break users). What do you think?

@ThomasRaoux I would really like to do that, but linalg.generic allows the mixed case, when you have memrefs and tensors at the same time and some folks are using it for some reason.