<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 29, 2014 at 3:27 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"><span class=""><blockquote type="cite"><div dir="ltr"><div class="gmail_extra">Well in essence that is what we are currently doing, usually
          by stripping the flags in the DAG.</div>
      </div>
    </blockquote></span>
    I think I wasn't quite clear enough.  We currently run InstCombine
    in multiple places in the pass ordering.  What if we had early runs
    of inst combine preserve flags as the first priority.  The runs
    closer to CGP would instead prioritize any legal optimization,
    regardless of whether it preserved flags or not.  Another way to
    state this would be that we simply pull the point we (potentially)
    drop flags a bit earlier in the pipeline - in particular, before the
    last point we run instcombine.<br></blockquote><div><br></div><div>We have the DAG Combiner which is essentially the last combine run. It's not InstCombine, but in theory this is where we would make such transformations today.</div><div><br></div><div>What I'm trying to say is that we already have this in principle, we've just pegged the "when" to be very late. We could move it forward if we had some significant evidence doing so helped lots of things without making anything worse, I just don't think anyone really has that kind of information.</div><div><br></div><div>This of course doesn't help the fact that there are two competing canonical forms. We end up picking one in the core of the pipeline and we will always see tradeoffs from whichever form we pick (for example in knock-on simplifications). </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
    <blockquote type="cite">
      <div dir="ltr">
        <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. </div>
      </div>
    </blockquote></span>
    So essentially this comes down to a case by case profitability
    analysis and there's no good answer.  Understood.  :)<br>
    <br>
    One interesting observation is that, so far, the cases I've seen
    where missing flags inhibit optimization, those flags can be
    re-derived from the IR in it's current form (with sufficient
    effort).</blockquote><div><br></div><div>I don't follow. The transforms which would require dropping flags would fire in many more places than just the one that gave rise to this thread, and would drop flags that we have no way of recomputing.</div><div><br></div><div>I don't think we're preserving flags in any cases where there is another canonical form that is mathematically simpler and inherently preserves the semantics. The problem is that the "simpler" form (thinking in terms of arithmetically simpler) specifically makes the flags impossible to recover.</div></div></div></div>