<br><br><div class="gmail_quote">On Fri Jan 09 2015 at 02:36:39 Philip Reames <<a href="mailto:listmail@philipreames.com">listmail@philipreames.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    <br>
    <div>On 01/08/2015 01:15 AM, Chandler
      Carruth wrote:<br>
    </div>
    <blockquote type="cite">
      <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>> 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><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><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>
    </blockquote></div><div bgcolor="#FFFFFF" text="#000000">
    I agree here.</div><div bgcolor="#FFFFFF" text="#000000"><br>
    <blockquote type="cite">
      <div dir="ltr">
        <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>
    </blockquote></div><div bgcolor="#FFFFFF" text="#000000">
    This is close enough to my own interests that if you can create a
    small test case, I'll take a serious look at fixing it.  I'm not
    going to go too far, but if it ends up being a simple fix, I'd like
    to have this work.  Please file a bug with your IR fragment. <br></div></blockquote><div><br></div><div><a href="http://llvm.org/bugs/show_bug.cgi?id=22168">http://llvm.org/bugs/show_bug.cgi?id=22168</a><br></div><div><br></div><div>Cheers,</div><div>Andrew</div></div>