User Details
- User Since
- Feb 2 2017, 2:24 AM (206 w, 4 d)
Today
This is an unreasonable relaxation IMO.
I'm looking into rewriting the part that requires AffineNormalizer, stay tuned.
Sat, Jan 16
Thu, Jan 14
Thanks!
Wed, Jan 13
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!
Tue, Jan 12
LGTM, thanks!
Sun, Jan 10
Sat, Jan 9
There are a few typos in the commit message.
Fri, Jan 8
Wed, Jan 6
Looks good but let's please simplify the Value source part.
Great, much nicer, thanks!
Tue, Jan 5
+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 !
Wed, Dec 30
Tue, Dec 29
LGTM, thanks!
Dec 18 2020
Apply fix.
clang-tidy
Address.
Rebase on a better Linalg.md
Rebase
Drop debug spew.
Rebase
Finish the impl.
Dec 17 2020
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.
Dec 16 2020
Thanks!
Dec 15 2020
well you need at least some test here :p
Dec 11 2020
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
Dec 10 2020
LGTM
Dec 9 2020
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.
Dec 8 2020
Dec 7 2020
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
Dec 4 2020
Great, thanks for refactoring this!
Dec 3 2020
Very cool, thanks River!
I have a bunch of use cases for this :)
Very cool, thanks for pushing this @ThomasRaoux !
Nov 30 2020
Poking a bit around I see this build: http://lab.llvm.org:8011/#/builders/135/builds/110
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.