<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 10, 2017, at 10:19 AM, Hal Finkel via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
  
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type" class="">
  
  <div bgcolor="#FFFFFF" text="#000000" class=""><p class=""><br class="">
    </p>
    <div class="moz-cite-prefix">On 11/10/2017 11:12 AM, Amara Emerson
      via llvm-dev wrote:<br class="">
    </div>
    <blockquote cite="mid:6E33B312-1716-4338-AF18-E4D2CC51CC59@apple.com" type="cite" class="">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
      Hi everyone,
      <div class=""><br class="">
      </div>
      <div class="">This RFC concerns the design and architecture of a
        generic machine instruction combiner/optimizer framework to be
        developed as part of the GISel pipeline. As we transition from
        correctness and reducing the fallback rate to SelectionDAG at
        -O0, we’re now starting to think about using GlobalISel with
        optimizations enabled. There are obviously many parts to this
        story as optimizations happen at various stages of the codegen
        pipeline. The focus of this RFC is the replacement of the
        equivalent of the DAGCombiner in SDAG land. Despite the focus on
        the DAGCombiner, since there aren’t perfect 1-1 mappings between
        SDAG and GlobalISel components, this may also include features
        that are currently implemented as part of the target lowerings,
        and tablegen isel patterns. As we’re starting from a blank
        slate, we have an opportunity here to think about what we might
        need from such a framework without the legacy cruft (although we
        still have the high performance bar to meet).</div>
      <div class=""><br class="">
      </div>
      <div class="">I want to poll the community about what future
        requirements we have for the GISel G_MI optimizer/combiner. The
        following are the general requirements we have so far:</div>
      <div class=""><br class="">
      </div>
      <div class="">
        <ol class="MailOutline">
          <li class="">It should have at least equivalent, but hopefully
            better runtime/compile time trade off than the DAGCombiner.</li>
          <li class="">There needs to be flexibility in the design to
            allow targets to run subsets of the overall optimizer. For
            example, some targets may want to avoid trying to run
            certain types of optimizations like vector or FP combines if
            they’re either not applicable, or not worth the compile
            time.</li>
          <li class="">Have a reasonably concise way to write most
            optimizations. Hand written C++ will always be an option,
            but there’s value in having easy to read and reason about
            descriptions of transforms.</li>
        </ol>
        <div class=""><br class="">
        </div>
      </div>
      <div class="">These requirements aren’t set in stone nor complete,
        but using them as a starting point: a single monolithic “Generic
        MI combiner” component doesn’t look like the right approach. Our
        current thinking is that, like we’ve done with the Legalizer,
        the specific mechanics of the actual optimization should be
        separated into it’s own unit. This would allow the combines to
        be re-used at different stages of the pipeline according to
        target needs. Using the current situation with instcombine as an
        example, there is no way to explicitly pick and choose a
        specific subset of IC, it’s only available as a whole pass with
        all the costs that entails.</div>
      <div class=""><br class="">
      </div>
      <div class="">The reasoning behind req 3 is that there may be
        compile time savings available if we can describe in a
        declarative style the combines we want to do, like it’s
        currently possible with tablegen patterns. This hasn’t been
        proven out yet, but consider an alternative where we use the
        machine instruction equivalent of the IR/PatternMatch tooling
        which allows easy and expressive matching of IR sub-trees. A
        concern I have with using that as the main approach to writing
        combines is that it’s easy to add new matchers in an routine
        which re-computes information that’s previously been computed in
        previous match() attempts.</div>
    </blockquote>
    <br class="">
    I share this concern.<br class="">
    <br class="">
    <blockquote cite="mid:6E33B312-1716-4338-AF18-E4D2CC51CC59@apple.com" type="cite" class="">
      <div class=""> This form of back-tracking might be avoided if we
        can reason about a group of combines together automatically (or
        perhaps we could add caching capabilities to PatternMatch).</div>
    </blockquote>
    <blockquote cite="mid:6E33B312-1716-4338-AF18-E4D2CC51CC59@apple.com" type="cite" class="">
      <div class=""><br class="">
      </div>
      <div class="">What would everyone else like to see from this?</div>
    </blockquote>
    <br class="">
    The current DAGCombine, being constructed on top of SDAG, has a kind
    of built-in CSE and automatic DCE. How will things change, if
    they'll change, in this new model?<br class=""></div></div></blockquote><div class="">Hi Hal,</div><div class=""><br class=""></div><div class="">I suspect one option is to have a separate CSE pass, and the backends get to choose where exactly they plug in their pipeline. I think DCE should be part of the combine pass (and the legalizer is about to start doing that as well).</div><blockquote type="cite" class=""><div class=""><div bgcolor="#FFFFFF" text="#000000" class="">
    <br class="">
    Thanks again,<br class="">
    Hal<br class="">
    <br class="">
    <blockquote cite="mid:6E33B312-1716-4338-AF18-E4D2CC51CC59@apple.com" type="cite" class="">
      <div class=""><br class="">
      </div>
      <div class="">Thanks,</div>
      <div class="">Amara</div>
      <br class="">
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br class="">
      <pre wrap="" class="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
    </blockquote>
    <br class="">
    <pre class="moz-signature" cols="72">-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
  </div>

_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></body></html>