[PATCH] D11530: RFC: LoopEditor, a high-level loop transform toolkit

[Adam Nemet via llvm-commits]

anemet added a comment.

Hi James,

Thanks very much for considering my comments.  I agree with this direction overall.  I have a few specific comments below:

> So it looks like this becomes:

> 

> - 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).


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.

> - [My own requirement] Make sure loopversioning works with non-leaf loops.


Makes sense.

> - Create a new class LoopWidening.

>   - I feel like this should be an abstract base class with concrete subclasses "LoopVectorizing" and "LoopInterleaving".


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.

> - [Later] create a similar LoopPeeling class, that hopefully should sit on top of the other two.


I am not sure there is much code to be shared between LoopPeeling and Widening.  Why do you think so?

> The names are up for bikeshedding.


Just for the record, I added the 'ing' ending to LoopVersioning to stress that I mean "version", the verb rather than the noun.

Thanks again,
Adam


Repository:
  rL LLVM

http://reviews.llvm.org/D11530