- User Since
- Jan 6 2015, 1:11 PM (306 w, 6 d)
Updating the change with https://reviews.llvm.org/D91503 to address some failures.
Reopening since the commit was reverted.
Fri, Nov 20
Reupload after reopening
Reopening to land after fix.
Thu, Nov 19
Wed, Nov 18
Address comments and rebase
Tue, Nov 17
Address comment and rebase
Sun, Nov 15
On a second look it seems like globbbing promotion with tile+fuse is maybe doing too much in one go. It might be better to avoid this. Instead https://reviews.llvm.org/D91503 exposes some utility functions that a client can use to figure out which views to promote. I am leaving this patch here for now, but intend to abandon this.
Fri, Nov 13
Same comment as Nicolas. Seems like it is easily generalizable to all Named ops.
I refactored my dependent changes to not require this patch. So abandoning this for now. Would be good to resolve this though.
Make Tile+Fuse only tile the fusable loops and leave the unfused loops
as is. The TileAndFuse pattern does the tiling of the unfused
Address other comments.
Make the tileAndFuse only tile the fusable loops. Also address comments.
Thu, Nov 12
Wed, Nov 11
Addressing missed minor comments.
Tue, Nov 10
Move pass to test pass.
Mon, Nov 9
Move missing files from parent change to here.
Move files to the dependent change.
Split out parts not related to Fusion itself into separate changes.
Rebase and fix test.
Seems like this changed to rely on having a single execution mode op per function. I think that is true. Approving this for landing.
Rebase and address comments
Sat, Nov 7
Fri, Nov 6
Tue, Nov 3
Just one question based on some questions.
Mon, Nov 2
Sun, Nov 1
Sat, Oct 31
Change is fairly straight-forward, but not sure what the issue with scf.parallel is. Is it the semantics of the op or the implementation of the distribution logic. If it is the latter, then maybe I can take a look there. Change looks fine as is though.
Thu, Oct 29
THanks for moving the method to Block. Other knowledgable people can comment on rest of the patch.
Tue, Oct 27
I guess we could add that part to an eraseArguments(ArrayRef<unsigned> indices) method on the Block class. That could be used by eraseArguments on the FunctionLike trait as well as your case. Is that what you mean?
Mon, Oct 26
Can this logic be generalized for all Regions? In the patch https://reviews.llvm.org/D90118 I need to drop arguments for region of an linalg::IndexedGenericOp. Having this method there would be more ergonomic.
Curious what you need this information for?
Thanks for the refactoring. Make sense now. Exciting!
Sun, Oct 25
Oct 24 2020
Seems to be some failing tests here. Will circle back after that is fixed.
Oct 23 2020