LGTM conditioned on reusing helpers rather than reinventing.

Generally looks good modulo the fact that this does not specify what happens with null handles.
I suspect we want to introduce NoOp before we can really use this new op you propose here?

would be nice to refactor to directly call into a new verifyContractionOpImpl helper in the same way that we have tensor::verifyInsertSliceOp

thanks!

Rebase

Rebase ad update BUILD.bazel

Update doc.

Rebase.

thanks! please also add a test to invalid.mlir to test we report this.

Better isolate specific canonicalization test from the rest of the infra.

Rebase + fixes.

Add another helper method.

Rebase.

In D128722#3615830, @mravishankar wrote:

I am not sure introducing an allocation semantics op at this level makes sense for all use cases. AFAICS, the bufferization allocation op should only be introduced "close to bufferization" and that might not be the case for all use cases. Definitely is not the case for within IREE. At the very least it should be optional to use this op.

Refactor transforms and make alloc_tensor optional.

Landed as 741f8f2bede58573560372bc219b2dec9a1d6643

Drop prefix case that is potentially dangerous.

Fix missing paren.

Cleanup.

Drop spurious files.

Rebase and address comment.

Thanks! Please update the title before landing.

Sorry @kazu, just saw this, thanks for fixing!

I wonder if there is an opportunity to split this PR in a few smaller and more composable pieces.

In D128443#3607624, @ftynse wrote:

In D128443#3606656, @mravishankar wrote:

High level comment, could we use TilingInterface for this. The advantage is that you don't need to couple this to the looping construct. I hope to purge the implicit coupling of scf within the implementation of tiling in Linalg. I found that separating the looping constructs from the tiling implementation makes things much simpler. It might help here as well

I looked at the interface and it seems that it would be more involved to implement this over the interface rather than here because of the exponentially expanding loop structure. So it would be preferable to me to have the actual tiling approach reviewed and exercised first, before eventually porting it to the interface in a separate commit.

Can you document the reason for this special casing?
Wouldn't this be better as a helper function that a client could call explicitly to know that bufferization won't do anything for them and they can avoid calling it in the first place ?
I am very concerned of anything that gives the impression to_memref and his twin are ok to have in this pass.

Nice!

Can we split into 1PR per op plz, also drop the NFC as tests are changing.

ok, but please drop the NFC part, the tests are changing.

We want to go away from affine map to specify layout (see in particular https://discourse.llvm.org/t/rfc-remove-bare-pointer-calling-convention/63419 ) and a bunch of other relates posts.
Can this PR just add the form you want for the address space?

Address.

Address comments.

Drop spurious dump.

Finish impl and add tests.