[PATCH] D11530: RFC: LoopEditor, a high-level loop transform toolkit
Michael Zolotukhin via llvm-commits
llvm-commits at lists.llvm.org
Wed Aug 19 17:43:54 PDT 2015
mzolotukhin added a comment.
Hi James,
Thanks for pushing it forward, I think we really need cleaning this up!
I don't think we'd like to have two independent vectorizers at the same time: 1) the old one, 2) based on the LoopEditor framework and invoked on simple loops (for beginning). The problem with that approach is that you're actually rewriting vectorizer from scratch, which should be really-really last resort. While I do admit that the code might be not ideal in places, I don't think we need to completely rewrite it from scratch. We can't be sure if they will converge in some observable future, and in attempts to converge them we don't know how the LoopEditor implementation will evolve when it covers all corner cases that the existing vectorizer supports.
So, I think the best way is to actually refactor existing code in small incremental steps (and by small I don't mean number of lines changed - I mean number of key points changed). For instance, you introduced a new class `Recurrence` - why not to do that in the original code? This way the existing code would become closer to what you want in the end, thus your patch will become smaller. I understand that it's not as easy as it sounds, but I think that's the proper way of pulling such changes. Another benefit of such approach is that it would be much easier to review, since NFC changes would be separated from new features, and thus we can both better check NFC changes for possible bugs and discuss the features on a higher level.
That said, in the end I do like to see API similar to what you proposed. I just think that growing it in parallel might back-fire.
Thanks,
Michael
Repository:
rL LLVM
http://reviews.llvm.org/D11530
More information about the llvm-commits
mailing list