<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On further thought, I don't think the extra directory structure is
    warranted yet.  We have several other frontend relevant docs at the
    top level so splitting off a directory without moving them would
    just make things more confusing.  <br>
    <br>
    Given that, tentative name is docs/PerfTips.rst and this will be
    going out as a code review to give time for others to comment on
    naming.  <br>
    <br>
    Philip<br>
    <br>
    <div class="moz-cite-prefix">On 02/25/2015 02:22 PM, Philip Reames
      wrote:<br>
    </div>
    <blockquote cite="mid:54EE4B2E.6020909@philipreames.com" type="cite">
      <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
      I'm moving forward with this now given no one has raised
      objections.<br>
      <br>
      Based on Sean's comments, the naming I'm going to use is:
      FrontendInfo/PerfTips<br>
      <br>
      I plan on committing an initial version based on what was
      discussed here without further review.  I'm going to keep the
      first version short, and then open it for others to contribute.<br>
      <br>
      Philip<br>
      <br>
      <div class="moz-cite-prefix">On 02/24/2015 02:13 PM, Sean Silva
        wrote:<br>
      </div>
      <blockquote
cite="mid:CAHnXoanNNq4sNthTr2-8CoB8Py1yZS7j0AGaAG0dBWwY09vHQg@mail.gmail.com"
        type="cite">
        <div dir="ltr">SGTM.
          <div><br>
          </div>
          <div>I like your idea of starting "perf tips" as sort of
            isolated guidelines for better IRGen. Should allow some nice
            incremental growth of the documentation. I expect some stuff
            will need a bit more discussion, so I would like this
            document to be in a directory docs/FrontendInfo/ or
            something like that (bikeshed) so that we can easily split
            out into new docs as needed for some breathing room, or to
            give some structure for readers to follow.</div>
          <div><br>
          </div>
          <div>Our optimizer and backends are our lifeblood, but
            frontends are our reason for existence. This kind of
            frontend-oriented documentation has been needed for a long
            time. Thanks for kicking it off!<br>
          </div>
          <div>
            <div>
              <div><br>
              </div>
              <div>-- Sean Silva</div>
            </div>
          </div>
        </div>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Mon, Feb 23, 2015 at 4:46 PM,
            Philip Reames <span dir="ltr"><<a moz-do-not-send="true"
                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">I'd like
              to propose that we create a new Performance Guide
              document.  The target of this document will be frontend
              authors, not necessarily LLVM contributors.  The content
              will be a collection of items a frontend author might want
              to know about how to generate LLVM IR which will optimize
              well.<br>
              <br>
              Some ideas on topics that might be worthwhile:<br>
              - Prefer sext over zext when value is known to be positive
              in the language (e.g. range checked index on a GEP)<br>
              - Avoid loading and storing first class aggregates (i.e.
              they're not well supported in the optimizer)<br>
              - Mark invariant locations - i.e. link to !invariant.load
              and TBAA constant flags<br>
              - Use globals not inttoptr for runtime structures - this
              gives you dereferenceability information<br>
              - Use function attributes where possible (nonnull, deref,
              etc..)<br>
              - Be ware of ordered and atomic memory operations (not
              well optimized), depending on source language, might be
              faster to use fences.<br>
              - Range checks - make sure you test with the IRCE pass<br>
              <br>
              If folks are happy with the idea of having such a
              document, I volunteer to create version 0.1 with one or
              two items.  After that, we can add to it as folks
              encounter ideas.  The initial content will be fairly
              minimal, I just want a link I can send to folks in reviews
              to record comments made.  :)<br>
              <br>
              Philip<br>
              _______________________________________________<br>
              LLVM Developers mailing list<br>
              <a moz-do-not-send="true"
                href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> 
                     <a moz-do-not-send="true"
                href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
              <a moz-do-not-send="true"
                href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev"
                target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
            </blockquote>
          </div>
          <br>
        </div>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>