<div dir="ltr"><div>Hi Adam,</div><div><br></div><div>I'm glad we're converging on a way forward!</div><div><br></div>> <span style="font-size:13.1999998092651px;line-height:19.7999992370605px">I am not sure there is much code to be shared between LoopPeeling and Widening.  Why do you think so?</span><div><span style="font-size:13.1999998092651px;line-height:19.7999992370605px"><br></span></div><div>Commonalities would be cloning all the blocks in a loop, detecting and hooking up reductions/inductions, and modifying the loop trip count. But you're right, "on top of" was not the right thing to say.</div><div><br></div><div>Cheers,</div><div><br></div><div>James</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, 12 Aug 2015 at 21:49 Adam Nemet via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">anemet added a comment.<br>
<br>
Hi James,<br>
<br>
Thanks very much for considering my comments.  I agree with this direction overall.  I have a few specific comments below:<br>
<br>
> So it looks like this becomes:<br>
<br>
><br>
<br>
> - Improvements to LoopVersioning to make LAA optional (choosing one loop or another shouldn't be tied to LAA - any predicate at all should do fine).<br>
<br>
<br>
Agreed.  Silviu's Assumption-based SCEV is already proposing to use LoopVer to host overflow checks.  I also have plans to add dynamic trip-count checks to allow a higher number of checks when we know the higher trip count will justify the the additional overhead.<br>
<br>
> - [My own requirement] Make sure loopversioning works with non-leaf loops.<br>
<br>
<br>
Makes sense.<br>
<br>
> - Create a new class LoopWidening.<br>
<br>
>   - I feel like this should be an abstract base class with concrete subclasses "LoopVectorizing" and "LoopInterleaving".<br>
<br>
<br>
There are certainly commonalities between interleaving and vectorization that we may need to be able leverage by delegating the differences to hooks.  I guess the way this shapes up will depend on the specifics of how the code will be split out from the Loop Vectorizer.  It will initially be probably pretty close to structure of code in the vectorizer.<br>
<br>
> - [Later] create a similar LoopPeeling class, that hopefully should sit on top of the other two.<br>
<br>
<br>
I am not sure there is much code to be shared between LoopPeeling and Widening.  Why do you think so?<br>
<br>
> The names are up for bikeshedding.<br>
<br>
<br>
Just for the record, I added the 'ing' ending to LoopVersioning to stress that I mean "version", the verb rather than the noun.<br>
<br>
Thanks again,<br>
Adam<br>
<br>
<br>
Repository:<br>
  rL LLVM<br>
<br>
<a href="http://reviews.llvm.org/D11530" rel="noreferrer" target="_blank">http://reviews.llvm.org/D11530</a><br>
<br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
</blockquote></div>