<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br>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).</div></blockquote><div><br></div><div>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. </div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"> Also, the relationship to the vectorization cost model seemed unclear. </div></blockquote><div><br></div><div>Yes, the cost model should be completely different. The SLP API looks like this:</div><div><br></div><div><pre class="fragment" style="font-family: Fixed, monospace; font-size: 13px; border: 1px solid rgb(204, 204, 204); background-color: rgb(245, 245, 245); margin: 4px 8px 4px 2px; padding: 4px 6px; position: static; z-index: auto;">01669 R.buildTree(Operands);
<a name="l01670" style="color: rgb(37, 46, 120);"></a>01670
<a name="l01671" style="color: rgb(37, 46, 120);"></a>01671 <span class="keywordtype" style="color: rgb(96, 64, 32);">int</span> Cost = R.getTreeCost();
<a name="l01672" style="color: rgb(37, 46, 120);"></a>01672
01674 <span class="keywordflow" style="color: rgb(224, 128, 0);">if</span> (Cost < CostThreshold) {
01676 R.vectorizeTree();</pre><div><br></div><div>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. </div><div> </div></div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">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.<br></div></blockquote><div><br></div><div>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 ?</div><div><br></div></div><div>Thanks,</div><div>Nadav</div></body></html>