Aart J.C. Bik received his PhD from the Leiden University in 1996. From 1998 to 2007, he worked at Intel, where he was the lead compiler architect of automatic vectorization in the Intel C++/Fortran compilers. In 2007, he moved to Google, where he has worked on compilers for ART and the Dart VM. He is now a member of the MLIR codegen team, focusing on compiler support for sparse tensor computations.
- User Since
- Jan 10 2020, 10:13 AM (124 w, 22 h)
I really like the direction this is going in, so we have one centralized mechanism to reason on allocation (and deallocation) of the buffers for tensors!
In the long run, it would be nice to have bufferization.de_alloc_tensor() as well, and have one mechanism that inserts those, independent of dense/sparse tensors.
Note that there is this parallel effort to unify our tensor initialization ops (see https://reviews.llvm.org/D126180).
So let's brainstorm offline to come up with another solution.
Thu, May 26
rebased with main
added tests for c128 and c64, ranked and unranked, memrefs
Wed, May 25
Onward to feature completeness!
Very neat. The general idea LGTM but I leave to it our math experts to approve.
Tue, May 24
Fri, May 20
Excellent work, Bixia!
Nice progress. One comment.
Thu, May 19
Oh, nice, I wonder if that makes reading the very large tensors slightly faster again!
Tue, May 17
Nice! Very fast. A few nits, but good to go.
Mon, May 16
Good to go after the required rebasing and merging.
I like this a lot! You will have to rebase for my complex change (sorry), but good to submit without review after that.
correct include for complex type
Fri, May 13
Jumping a bit ahead in the stack, but this delta is good to go once base goes in as well.
Thu, May 12
discussed offline: only one padding element
TAB -> spaces
LGTM for sparse
Thanks for your patience during the review, Wren. It has been a long road, but nice to see this new abstraction!
Changes look good, and it is of course good to require the minimum required type. But is there a major advantage of doing it this way? (follow up or otherwise)?
Wed, May 11
Thanks for the fix. I always fall back to my 90ties C style ;-)
The reported failure seems unrelated but please double-check too.
Thanks for fixing this so quickly!
Fri, May 6
Thank you kindly, Mehdi, as always, for watching our BUILD so closely and proactively fixing it!
Thu, May 5
Do you have some experimental validation to report before we proceed with this?
Wed, May 4
Nice! Thank you for doing this so quickly!
Tue, May 3
Mon, May 2
A few last comments, but I am giving you the LGTM, since I think this is ready to go in, so we can work on refining the few remaining issues.
Thanks for your patience during the review, and thanks for this contribution!
Thu, Apr 28
Apr 27 2022
A few last comments. Sorry for being nitpicky on this, rest assured I really like the work, I am just a bit particular on certain things.
Also, can you please make a pass over all my comments and mark them "Done" (or comment on them otherwise).
That makes the re-review a bit easier, since a lot of my past comments still show up as unresolv.ed
added note on change to struct