<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 29, 2014 at 2:37 PM, Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.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="adM"><div class=""><div>On 12/23/2014 04:55 PM, Chandler
      Carruth wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Tue, Dec 23, 2014 at 4:51 PM,
            Sanjoy Das <span dir="ltr"><<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.com</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> Perhaps it would help to explain it
                slightly differently: There are<br>
                > optimizations which we can only perform by
                *removing* any no-wrap flags. But<br>
                > we don't know whether that optimization or the
                no-wrap flags is more<br>
                > important, and so we have to make a choice, and the
                choice is to preserve<br>
                > the flags at the expense of the transformation.
                Thus, adding flags can<br>
                <br>
              </span>Is this choice always in favor of retaining the
              flags?  Or is it a<br>
              per-transform decision?</blockquote>
          </div>
          <br>
          per-transform, but at least recently I've been seeing a trend
          towards preserving flags.</div>
      </div>
      <br>
    </blockquote></div></div>
    Chandler, thanks for reframing this.   This suddenly makes a lot
    more sense to me.  :)<br>
    <br>
    This is starting to seem like an canonicalization issue.   If we
    canonicalized to the form with flags, and deferred flag stripping
    until later in the optimization pipeline, would that get us a better
    practical result? </blockquote></div><br>Well in essence that is what we are currently doing, usually by stripping the flags in the DAG.</div><div class="gmail_extra"><br></div><div class="gmail_extra">This doesn't really get us a butter practical result because the point of making the transform in instcombine is to allow the result to in turn re-combine with something else interestingly.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The "solution" I really know for this kind of thing is to explode the space by tracking both forms. We actually do some of this today. If you have an outer combine that needs an inner combine that strips flags, you just write the outer combine to handle the inner expression in its more complex flag-bearing form. The problem is that this grows the number of patterns necessary for the outer combine in a combinatorial way, so there are very severe limits on how much of this we can do. Other approaches to this avoid "combining" and instead form axioms about values so that they can represent multiple alternate axioms throughout the optimization pipeline and select between them very late rather than committing early. However, I'm not aware of any production compilers that have managed to make this scale up. =/</div><div class="gmail_extra"><br></div><div class="gmail_extra">I think this is just a fundamental limitation of a combine-based (that is, through mutations of the IR) scalar optimizer. The only way you truly avoid it is to have a mutation-free scalar optimizer which would just be a totally different design from LLVM's (IMO).</div></div>