<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 14, 2014 at 10:11 AM, 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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div id=":7a2" class="" style="overflow:hidden">>> + correlated-propagation<br>
<br>
A little worried about this.<br>
<br>
>> + instcombine<br>
<br>
I'm *very* concerned about rerunning instcombine, but understand it may help cleanup the vectorized preheader.<br></div></blockquote><div><br></div><div>Why are you concerned? Is instcombine that slow? I usually don't see huge overhead from re-running it on nearly-canonical code. (Oh, I see you just replied to Hal here, fair enough.</div><div> </div><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"><div id=":7a2" class="" style="overflow:hidden">
<br>
>> + licm<br>
>> + loop-unswitch<br>
<br>
These should limited to the relevant loop nest.<br></div></blockquote><div><br></div><div>We have no way to do that currently. Do you think they will in practice be too slow? If so, why? I would naively expect unswitch to be essentially free unless it can do something, and LICM not much more expensive.</div><div> </div><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"><div id=":7a2" class="" style="overflow:hidden">
<br>
>> + simplifycfg<br>
<br>
OK if the CFG actually changed.<br></div></blockquote><div><br></div><div>Again, we have no mechanism to gate this. Frustratingly, the only thing I want here is to delete dead code formed by earlier passes. We just don't have anything cheaper (and I don't have any measurements indicating we need something cheaper).</div><div> </div><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"><div id=":7a2" class="" style="overflow:hidden">
<br>
>> + instcombine<br>
<br>
instcombine again! This can’t be good.<br></div></blockquote><div><br></div><div>I actually have no specific reason to think we need this other than the fact that we run instcombine after simplifycfg in a bunch of other places. If you're looking for one to rip out, this would be the first one I would rip out because I'm doubtful of its value.</div><div> </div><div><br></div><div>On a separate note:</div><div><br></div><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"><div id=":7a2" class="" style="overflow:hidden">
<br>>> + early-cse<br><br>Passes like loop-vectorize should be able to do their own CSE without much engineering effort.<br><br>>>  slp-vectorize<br>
>> + early-cse<br>
<br>
SLP should do its own CSE.</div></blockquote></div><br></div><div class="gmail_extra">I actually agree with you in principle, but I would rather run the pass now (and avoid hacks downstream to essentially do CSE in the backend) than hold up progress on the hope of advanced on-demand CSE layers being added to the vectorizers. I don't know of anyone actually working on that, and so I'm somewhat concerned it will never materialize.</div></div>