Fri, Nov 15
I don't see anything else wrong with this. LGTM if you rename the LE predicate.
Addressed @labath's comment (test run in progress). Thanks for having a look!
Thu, Nov 14
Wed, Nov 13
Regarding the change to return const, I'm not convinced that's a good idea (we actually have a clang-tidy check that warns about that). I think it would be better to either name those temporaries or use std::make_tuple instead of std::tie (whichever you prefer).
Tue, Nov 12
Update test checks. Also brush it up a bit so it fits better with the rest of the tests in the file.
Mon, Nov 11
Tue, Nov 5
Mon, Nov 4
The text itself LGTM.
Thu, Oct 31
Just a few more typos and stuff.
Tue, Oct 29
Thanks, looks great!
Mon, Oct 28
Thanks for writing this up! I just have a few suggestions and one small bug to point out (I can't figure out how to comment on a png file, so I'll write it here).
Oct 18 2019
Thanks, LGTM then!
Oct 17 2019
Could you be a little more specific? I just ran a build with BUILD_SHARED_LIBS=ON and it seemed to work.
Oct 2 2019
This looks good to me, maybe wait a while to see if anyone else has any further comments.
Oct 1 2019
Sep 25 2019
I'm not very familiar with this area, but it seems like a sensible fix.
Sep 24 2019
I suspect 'ScalableSize' is the wrong term now; 'TypeSize' may be better. Thoughts?
Sep 16 2019
I think all the outstanding comments have been addressed. LGTM.
Sep 4 2019
Sep 2 2019
Just some drive-by suggestions :)
Aug 30 2019
Does anyone like Sander's suggestion to make ScalableSize (or whatever we end up naming it) the return value for all size queries and provide an overloaded cast operator to transparently work with existing code comparing against unsigned values? Or is it preferable to keep the current split?
Aug 1 2019
Several more general comments:
- Should all the getXSize assert when called on a scalable type? I see that for MVT::getSizeInBits and for Type::getPrimitiveSize, but not for the others. This should also be made clear in the comments for each of them.
- Great test for the IR, thanks!
- I don't see any test for the CodeGen stuff though. Is it possible to add one? (If not, maybe add the changes to EVT etc when we can actually test them).
- Ditto for TableGen (or if that's too difficult/hairy to test, just update the commit message to explain exactly why the change belongs in this patch).
Jul 31 2019
Jul 30 2019
Some people might be interested just in compiling LLVM (e.g. fetching some release sources from releases.llvm.org and building them). We should probably keep the package list here focused on that. If we want to add git at all, we should probably mention it somewhere else. I'm not sure where that would be - I suppose somewhere where it makes sense to worry about the minimum version, e.g. where the git-llvm script is concerned. Do we have any other reason to bind ourselves to a certain minimum version of git?
Jul 26 2019
Jul 23 2019
Thanks for the comments.
I think this patch is difficult to review. It covers many different source files with only a small unit test to check the correctness. This isn't very robust against future changes and it makes it hard to know exactly what is and isn't supported.
Yeah, I was worried about that -- this is basically the size queries alone without anything actually using scalable vectors. It demonstrates roughly where changes will be needed, but doesn't actually change the surrounding code to use e.g. getElementCount instead of getNumElements.
I would find it much easier to review with an incremental strategy based on regression tests. For instance, with ToT opt, the attached testcase fails (error: '%r' defined with type '<4 x i1>' but expected '<vscale x 4 x i1>'). I would add a patch to fix that, and maybe other similar, really simple cases. We could then proceed to more complex examples, run some of the passes that come after the vectorizer on them, and progressively fix the places required to make them pass, with focused tests for each hurdle that we run into. It shouldn't be too hard to reduce such snippets from the tests you've already been running.
An incremental approach sounds good; assuming nobody objects, I'll remove most of the code in this patch and just leave the core mechanism behind (in enforcing mode) and add in that test case. We can fill in the other cases as we enable codegen/acle/autovec in separate patches.
Jul 22 2019
Jul 19 2019
FWIW, I think the tests look great. Would be nice if someone more experienced with clang could also have a look though.
Jul 18 2019
Jul 17 2019
Jul 15 2019
Jul 2 2019
This looks much better, thanks! Shouldn't there be more tests, e.g. for mangling and maybe the ASTImporter?
Jul 1 2019
Thanks, committed in r364778!
Jun 28 2019
Looks good to me, please commit
(@rovka - this is at least a short-term fix, I'm approving this to unbreak LLVM's mainline - feel free to refix with other ideas if you have any (also happy to discuss this further with you here, IRC, or elsewhere on the mailing lists)
Jun 27 2019
Just a few nits/suggestions.
Jun 25 2019
Jun 24 2019
Thanks so much for working on these patches Diana! It's tricky business, can you be sure to run test suites thoroughly before committing if you haven't already.
LGTM too if we remove the last packRegs use and delete the IRTranslator pack/unpackRegs() implementations.
Jun 20 2019
Thanks for the review! More context for posterity though :)
Oops! Fixed :)