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.

In D141804#4055148, @mravishankar wrote:

This is an unnecessary change that just causes downstream churn. Not sure it is worth it

In D141807#4055290, @mravishankar wrote:

Actually when I deleted some similar code I posted a PSA for it (https://discourse.llvm.org/t/psa-retire-tileandfuselinalgops-method/63850). There might be users of this that might be using this in a load-bearing fashion. Better to get community input first.

Why is this needed? DimOp always takes Value for the dimension index. There is no index attribute, which would allow to fold constants into the dimOp. With the current DimOp it is easier to call getValueOrCreateConstantIndexOp when DimOp::build is called.