- User Since
- Feb 2 2017, 2:24 AM (207 w, 5 d)
Address and rebase.
class -> struct
Sun, Jan 24
Keep a ValueRange based builder around.
Undo bad fix and fix use-after-move properly.
Fix use after move.
Looks great, thanks @springerm !
I am not disputing that this is useful, but at least within IREE, I am not sure we can actually set a static tile size at the time of tiling. In IREE with the linalg on tensors path the tile size has to by dynamic during tile and distribute since it is done at the Flow dialect level where no backend specific information is available. The static tile size picked while tiling might not be one that is best for the backend that is targeted (information that is available only at the HAL level). So making this padding as part of the tiling transformation might not work out for IREE. My understanding then is that if we separate out the padding parts from the tiling transformation itself then it has the same constraints/restrictions as promotion, but with the advantage of SSA use-def chains.
Attempt to appease win, 3rd take..
Attempt to appeas win, again..
It should be easy to extend promotion to abort if it doesnt figure out the static sizes when "promotion" is applied to ops with tensor semantics.
Fri, Jan 22
Attempt to appease win.
Thu, Jan 21
This looks good.
Can you please add one test per verifier failure to test/Dialect/Linalg/invalid.mlir ?
Once these are in, this is good to go.
Wed, Jan 20
+1 on the negative tests but IIRC there is no size check/verifier automatically generated from the affine maps?
This is generally something we want for all linalg ops but it is missing atm.
Thanks for pushing on this Hanhan.
The impl. needs to be a little more involved to allow different numbers of low and high padding values.
You'll also need extra builders and accessors to make things easier to manipulate, they can be added on a per need basis.
You can look at Subview/Subtensor and the OffsetSizesAndStridesInterface for similarly looking code.
Refactorings to reuse code are most welcome, if reasonable.
Tue, Jan 19
Mon, Jan 18
This is an unreasonable relaxation IMO.
I'm looking into rewriting the part that requires AffineNormalizer, stay tuned.
Sat, Jan 16
Thu, Jan 14
Wed, Jan 13
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
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 !