[PATCH] Loop Rerolling Pass

[Nadav Rotem]

> 
> I thought about this, but it was not clear to me that reusing the SLP-vectorizer's internals was the right thing to do. For one thing, I wanted to be able to handle arbitrary function calls, and other non-vectorizable instructions (in addition to the distray case, the s353 loop in TSVC/LoopRerolling is also non-vectorizable).

We can teach the SLP tree building to construct trees with non vectorizable functions (such as getc).  The tree building phase is just about finding isomorphic trees.  

> Also, the relationship to the vectorization cost model seemed unclear.

Yes, the cost model should be completely different.  The SLP API looks like this:

01669     R.buildTree(Operands);
01670 
01671     int Cost = R.getTreeCost();
01672 
01674     if (Cost < CostThreshold) {
01676       R.vectorizeTree();

First, you create the tree. Next, you get the cost. And finally, you vectorize. If you decide to use it you would only use the first call for constructing the tree. 
 

> Finally, I needed to confirm loop dependence ordering and full coverage of the loop, both of which would have required significant extension to what the SLP vectorizer provides.

Loop coverage is trivial. You just need to check that all of the instructions in the loop are inside one of the trees. There is already a map that contains all of the instructions.  I don’t understand the loop-dependence ordering problem. Can you explain the problem ?

Thanks,
Nadav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131016/7760cb11/attachment.html>