This is an unreasonable relaxation IMO.
I'm looking into rewriting the part that requires AffineNormalizer, stay tuned.

Thanks!

Thanks!

ok, my apologies, this looks great, I'll do a proper review in a bit but consider it landed :)

On one hand, it's great to see minimal additional patterns translate to new capabilities, very nice!

LGTM, thanks!

There are a few typos in the commit message.

Looks good but let's please simplify the Value source part.

Great, much nicer, thanks!

+1 for the extra test.

Going through my unreviewed stack, note that with the revamp of linalg on tensors @pifon2a sent a diff today that implements the functionality with out tensors,

Thanks @pifon2a !

LGTM, thanks!

Apply fix.

clang-tidy

Address.

Rebase on a better Linalg.md

Rebase

Drop debug spew.

Rebase

Finish the impl.

Thanks @ThomasRaoux

+1 it's fine for now and unlocks a bigger piece of the puzzle.
We can refactor and cleanup as followups: subview crams together 3 variadic static / dynamic + canonicalizations.
There is a nicer future where we can define a generic pair of variadic operand + attribute + canonicalizations for all such things.

Thanks!

well you need at least some test here :p

Line length.

.

CMake

Fixes post rebase.

Address and rebase

Looks good!

It's nice that we actually don't need to change op semantics to support "init_tensor form" and that all semantics can be dealt with just in tiling.
However we need a better abstraction and documentation to avoid leaking the op + init or result tensor implementation detail into the tiling implementation.

Also @pifon2a

LGTM

I'm -1 on the proposed name change: LLVM has {insert|extract}{element|value}, op names are globally consistent with that terminology.

As discussed offline, this will be revamped in a relatively near future.
Fine to unblock for now assuming presubmits pass.

Once my comments are addressed I am happy to land this.
I think the additional layer of tablegen discussed in https://llvm.discourse.group/t/exposing-llvm-ops-to-the-mlir-type-system/2290/11 and having everything in the LLVM dialect is a cross-cutting change that should be done separately and unified across all 3 dialects (AVX512, ArmNeon, ArmSVE).

CMake

Update commit message

Address and rebase

Great, thanks for refactoring this!

Very cool, thanks River!
I have a bunch of use cases for this :)

Very cool, thanks for pushing this @ThomasRaoux !

Poking a bit around I see this build: http://lab.llvm.org:8011/#/builders/135/builds/110

In D92166#2422886, @rovka wrote:

Hi,

This seems to break several buildbots that don't build the x86 backend, e.g. http://lab.llvm.org:8011/#/builders/135/builds/90.
Could you please take a look?

Thanks!

I'm a bit concerned about bringing this into MLIR without stronger constraints than what is allowed in LLVM. Unfortunately even if we document restriction, it isn't clear how we can enforce anything? The way inline assembly is an open-door to "anything" seems quite scary to me.

In D92216#2421199, @jpienaar wrote:

"I didn't care enough to model this as an intrinsic or op/my machine scheduler modelling isn't good enough/I need an escape hatch to do things which are invalid but work for my case".