<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 08/22/2015 04:51 PM, David Jones via
      llvm-dev wrote:<br>
    </div>
    <blockquote
cite="mid:CAEwg-Q+qq6U+RiFBFE968n30xW_GHDPmqOtcCYpW6v-hVbH4dQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div>
            <div>
              <div>A somewhat more general question:<br>
                <br>
              </div>
              What characteristics of generated IR contribute to poor
              optimization/code generation times?<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    I don't believe we have any documentation on this topic at this
    point.  The performance tips for frontend authors page has some
    information (<a class="moz-txt-link-freetext" href="http://llvm.org/docs/Frontend/PerformanceTips.html">http://llvm.org/docs/Frontend/PerformanceTips.html</a>),
    but not much.<br>
    <br>
    In general, the farther something is from reasonable C/C++ code
    (including machine generated code from various common frameworks)
    the less likely all the issues are to have been worked out.  <br>
    <br>
    If you wanted to start some documentation, that would be a very
    constructive way to gather information that will help you and
    others.  <br>
    <blockquote
cite="mid:CAEwg-Q+qq6U+RiFBFE968n30xW_GHDPmqOtcCYpW6v-hVbH4dQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div>
            <div><br>
            </div>
            I recently found a pathological case in my own code of data
            tables that caused poor performance in the IR verifier.<br>
          </div>
        </div>
      </div>
    </blockquote>
    This was a performance bug.  They exist.  Please file them so they
    can get fixed.<br>
    <br>
    In particular, you may find various passes which need cutoffs added
    (due to the super-linear scaling inherent in them).  Feel free to
    file bugs - preferably with test cases! - for these.  Patches are
    even better of course.  :)<br>
    <blockquote
cite="mid:CAEwg-Q+qq6U+RiFBFE968n30xW_GHDPmqOtcCYpW6v-hVbH4dQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div><br>
          </div>
          In general, I am not happy with the performance of LLVM on my
          code, so I know I need to do better. But how? I have a few
          ideas, but trying any of them could be time-consuming, with no
          guaranteed return at the end of it.<br>
        </div>
      </div>
    </blockquote>
    Honestly, you're the only person who can do these experiments.  You
    can try talking to others in the community, but if you're not
    willing to run experiments, your results will be poor.  Having data
    to share greatly increases the likelihood someone else will be
    interested enough to help.  <br>
    <br>
    Can you share your current numbers?  i.e. Why are you "not happy"?<br>
    <blockquote
cite="mid:CAEwg-Q+qq6U+RiFBFE968n30xW_GHDPmqOtcCYpW6v-hVbH4dQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        Currently, I don't emit TBAA metadata. I have a hunch that doing
        so might speed up compilation, as alias analyses can be reduced
        in size, but I don't know that for sure, or how much of a
        benefit it would be. Yes, I need to do this in any case, but if
        my users complain of long compile times, I'd like to know what
        to work on first.<br>
      </div>
    </blockquote>
    I really doubt failing to emit TBAA metadata will help.  In
    particular, my general experience has been that improving compile
    time happens mostly by making the optimizer more effective (so that
    other passes see less code), not by crippling it.  <br>
    <blockquote
cite="mid:CAEwg-Q+qq6U+RiFBFE968n30xW_GHDPmqOtcCYpW6v-hVbH4dQ@mail.gmail.com"
      type="cite">
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Sat, Aug 22, 2015 at 6:57 PM,
          Michael Zolotukhin via llvm-dev <span dir="ltr"><<a
              moz-do-not-send="true"
              href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
            <br>
            Several passes would have troubles with such code (namely,
            GVN and JumpThreading). Recently we exposed similar issues
            when new more aggressive unrolling heuristic was implemented
            - we unrolled big loops expecting that the linear code would
            be then optimized, and it indeed was optimized, but compile
            time regressed significantly. But probably some of these
            issues have been fixed already - I didn’t check.<br>
            <br>
            Thanks,<br>
            Michael<br>
            <span class="">> On Aug 22, 2015, at 3:03 PM, Russell
              Wallace via llvm-dev <<a moz-do-not-send="true"
                href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>>
              wrote:<br>
              ><br>
              > How well does LLVM scale to many basic blocks? Let's
              say you have a single function consisting of a million
              basic blocks each with a few tens of instructions (and
              assuming the whole thing isn't trivially repetitive so the
              number of simultaneously live variables and whatever is
              large) and you feed that through the optimisers into the
              backend code generator, will this work okay, or will it
              take a very long time, or will it run into a scenario of
              'look, all compilers are designed on the assumption that
              nobody is going to write a million lines of code in a
              single function'? (Not that I'm planning to do so by hand
              either, I'm just thinking about certain scenarios in
              automatic code generation.)<br>
            </span>> _______________________________________________<br>
            > LLVM Developers mailing list<br>
            > <a moz-do-not-send="true"
              href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
            > <a moz-do-not-send="true"
href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=ygVmcuuQ1MUhRUoJm-IgPtgjmvM0byfjlHDg99vufEI&m=z0N7FJAyaeJqJqE_W9ltYzHHpYI5tfa3q7x8UoMNaLA&s=mVoa5Fp3pKx6PIZ3F96zYIKlJmBSyzqARoAtuu0ws5A&e="
              rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=ygVmcuuQ1MUhRUoJm-IgPtgjmvM0byfjlHDg99vufEI&m=z0N7FJAyaeJqJqE_W9ltYzHHpYI5tfa3q7x8UoMNaLA&s=mVoa5Fp3pKx6PIZ3F96zYIKlJmBSyzqARoAtuu0ws5A&e=</a><br>
            <br>
            _______________________________________________<br>
            LLVM Developers mailing list<br>
            <a moz-do-not-send="true"
              href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
            <a moz-do-not-send="true"
              href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
              rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
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>
  </body>
</html>