<div dir="ltr"><div class="gmail_extra">Just to add a few notes...</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 21, 2014 at 1:31 PM, Andrew Trick <span dir="ltr"><<a href="mailto:atrick@apple.com" target="_blank">atrick@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote type="cite"><div bgcolor="#FFFFFF" text="#000000">Chandler suggested a way around the problem. I'll work on that
    first.<br></div></blockquote><div><br></div></div><div>It is very difficult to deal with the LoopPassManager. The concept doesn’t fit with typical loop passes, which may need to rerun function level analyses, and can affect code outside the current loop. One nice thing about it is that a pass can push a new loop onto the queue and rerun all managed loop passes just on that loop. In the past I’ve seen efforts to consolidate multiple loop passes into the same LoopPassManager, but don’t really understand the benefit other than reducing the one-time overhead of instantiating multiple pass managers and some minor IR access locality improvements. Maybe Chandler’s work will help with the overhead of instantiating pass managers.</div>
</blockquote><div><br></div><div>Maybe, but currently I don't really understand the ideal state for loop pass pipeline formation. Maybe I'll sit down with you, Owen, and/or others that are more deeply involved in the loop passes to get a good design in my head. But we're not quite there yet. =]</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div>Anyway, I see no reason that the vectorizer shouldn’t run in its own loop pass manager.</div>
</blockquote><div><br></div><div>It turns out, this is all moot - the loop vectorizer *already* doesn't run as part of these loop passes. It runs on its own during the late optimization phase.</div><div><br></div><div>
If it is a loop pass at all, I would just suggest making it a function pass and being done with it. Then there will be no problems here. That make sense to you guys as well?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>I’m sure we could be more aggressive than we are currently at O3. If the vectorizer unroller’s conditions are too strict, we could consider calling the standard partial unroller only on the loops that didn’t get vectorized.</div>
<div></div></blockquote></div><br>I think we can be more aggressive across the board. I've got a pretty good conservative benchmark suite and rig for increasing the aggressiveness of these kinds of optimizations (it is very sensitive to code size and consists of macro benchmarks that aren't usually bottlenecked on a single loop). I'm going to try some basic relaxing of the unrolling thresholds in the loop vectorizer to see if there is at least an *obvious* better baseline level. Then we can see if there is more detailed tuning to do.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">However, I'd like to do that after the if-conversion issue is fixed if possible. I have bandwidth to do the evaluation of thresholds, but not really to hack on the if-conversion stuff. Any guesses if you guys will have time to look at that aspect?</div>
</div>