Thanks!

LGTM!

The re-oragnization looks good to me. I assume no changes in the patterns so I haven't looked into them.

Looks great!

LGTM, added a few nits

Thanks Lei!

LGTM but it would be good to have @christopherbate's opinion

LGTM

LGTM, added one more nit about file name.

Thanks for the clean up!

still looking, few nits for now

Looks good overall, added few nits

LGTM

In D144294#4138255, @nicolasvasilache wrote:

I am unclear why this special casing is needed...
I routinely convert higher-D ops into lower-D generic ops with rank-reducing patterns.
In my use cases, I am not relying on the named ops for further transformations / optimizations.

IMO this just points at the need to finally start that inverse generalization transform: linalg.generic -> linalg.named op.
I was still dragging my feet because I am still hoping we can do significantly better than special casing, but when the special casing leaks into N^2 land, it is time to just do it.

So bottom line, could you start a new file called Specialization.cpp with a functional transform API FailureOr<LinalgOp> specialize(linalg::GenericOp genericOp).

For this use case, you should only need:

if (isaContractionOpInterface(genericOp) && /*check indexing maps*/ && /*check reduction type*/)
  return rewriter.replaceOpWithNewOp<linalg::MatmulOp>(...);

That switch can grow over time and is the only place in the compiler where we need such logic.
This will compose with rank-reducing patterns that we have filtere over time to properly use rank-reducing slices.

In D144108#4134753, @nicolasvasilache wrote:

Thanks for addressing @qcolombet , I am fine with iterating from this and seeing where it goes.
I can see that it will not be in an ideal form for mapping im2col on device, I expect we will be able to evolve it iteratively.

Please wait for @mravishankar for a final confirmation

rebase and address review comment

please mark it as NFC

Thanks!

In D144113#4129557, @antiagainst wrote:

IMO, the accessor name could use some improvements---it's very confusing and error-prone just being getVectorType(); making it something like getSrcVectorType() would make it far easier to avoid pitfalls. At least for me, I need to read the impl to double check what it means by just getVectorType().

LGTM

Looks good to me. Would be better to have a test to at least make sure it doesn't crash or emit wrong code until everything is ready

awesome!

address review comment

Thanks!

In D143223#4111157, @qedawkins wrote:

@ThomasRaoux I added changes to the GPUToNVVM lowering to support integer types. Would it be better to move those changes to a separate revision?

Thanks for also adding lowering to nvvm!

What would happen if we run lowering to SPIRV or NVVM? We don't want to crash or miscompile.

Nice :) Thanks! Make sure to update the title and description.

Thanks!

LGTM

In D141804#4066465, @pifon2a wrote:

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.

I think this is the only valid argument against landing this PR in this whole thread.

I am also curious why linalg was used as a storage format. Are there many clients/models that use it instead of higher level dialects?