<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 7, 2015 at 11:05 AM, Peter Collingbourne <span dir="ltr"><<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> I don't know if this will ever be necessary, but another option is for llgo to grow its own IR on top of go/ssa. I'd rather not go there for this, though.<br>
<br>
<br>
</span>Agreed. FWIW, the long term direction I'd like to see is attempting to extend go/ssa with what we need (in this particular case, a native switch instruction).<br>
<span class=""><br>
> I did look to see if there was an existing pass, but again I couldn't see anything that looked relevant<br>
<br>
<br>
</span>If you grep for `SimplifyCFGOpt::FoldValueComparisonIntoPredecessors` you should find something.<br>
<span class=""><br>
> Geo-mean improvement of 0.49% (0.23% - 0.75% @ 95% CI)<br>
<br>
<br>
</span>Great! I'm a little surprised that we can do better than LLVM on its own, but maybe I don't understand what the simplifycfg code is doing.</blockquote></div><br>Just a peanut gallery comment, but I'm pretty disappointed that LLVM can't turn if-chains into switches for you. I think not dealing with switches sounds like a really reasonable simplification for a frontend to desire. The optimizer should fix this code, and should both be faster and more powerful in doing so.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Any interest in trying to make LLVM's switch formation powerful enough to catch the cases you care about? Or at least reducing the test case we missed? If we can do that, it seems like it would remove the ugliness from the approach by letting you generate "naive" switches with high confidence that they optimize appropriately?</div></div>