<div dir="ltr">On 28 August 2013 21:58, Eric Christopher <span dir="ltr"><<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Sure, it seems reasonable to me that this should be hoisted out to<br>

some analysis and then stuck in the general loop unrolling pass. What<br>
do you think?<br></blockquote><div></div></div><br></div><div class="gmail_extra">Hi Eric,</div><div class="gmail_extra"><br></div><div class="gmail_extra">The difference here, I assume, is that the LoopVectorizer has more information than the simple loop unrolling pass, and thus can know that a transformation is profitable.<br>
</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">We had similar discussions before, even in the Polly era: where does the analysis end and the implementation begins?</div><div><br>
</div><div>There was some consensus that vectorizers should have three (not necessarily distinct or unique) passes: </div><div> 1. The first pass, the annotation phase, where costs would be calculated, transformations would be validated and metadata would be written to loops, basic-blocks and, possibly, instructions. The Legalizer and the CostTable do that job, but doesn't annotate anything.</div>
<div> 2. The second pass would then do the target-independent transformation, based on the previous annotation. This is more or less what the current vectorizers do, trusting that step 1 is sure that the transformation is legal and worthy.</div>
<div> 3. A third pass would then do more target-specific changes, with sub-target information, like this very case, if you know your CPU is OOO. This is partially done by the cost tables and the TTI, but not explicitly.</div>
<div><br></div><div>Because step 1 is not annotating, that information can't be used outside the vectorizers, and because the cost tables and the target transform info are holding target-specific information, you don't (yet) need a third-stage. </div>
<div><br></div><div>But things start to get grey with the example Nadav gave. That seems more profitable on OOO CPUs, but probably not others, and since non-OOO CPUs are still being designed today, that might be a target-specific approach on a target-agnostic area. Also, since there is no annotation, other passes cannot profit from the information that the vectorizer calculated, throwing away precious cycles or duplicating code into the vectorizer.</div>
<div><br></div><div>So, I agree that we could do better, but we'll need some co-joint work on the vectorizer if we are to make it more generic while still maintaining its hard-earned performance boost on, at least, x86 and ARM.</div>
<div><br></div><div>On the other hand, maybe the loop-unrolling pass should be merged into the loop vectorizer...</div><div><br></div><div>cheers,</div><div>--renato</div></div></div>