<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>(I'm probably going to derail your thread, sorry about that.)</p>
    <p>I think at this point, we should just bite the bullet and make
      the switch to NPM by default for Clang's optimization pipeline. 
      Today.</p>
    <p>Why?  Because many of our downstream consumers have already
      switched.  Google has.  We (Azul) have.  I think I've heard the
      same for a couple other major contributors.  Why does this
      matter?  Testing.  At the current moment, the vast majority of
      testing the project gets is exercising NPM, not LPM.</p>
    <p>NPM is functionally complete for Clang optimization.  There might
      be a few missing cases around the sanitizers, but last I heard
      those were on the edge of being fixed.</p>
    <p>I think we should make the switch, and deal with any fall out as
      regressions.  If we made the change immediately after a release
      branch, we'd have several months to address any major issues
      before the next release.  <br>
    </p>
    <p>Philip<br>
    </p>
    <div class="moz-cite-prefix">On 7/22/20 2:39 PM, Arthur Eubanks via
      llvm-dev wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAPW48sopEcvadGK36NxP=gQiY8z40bcLs_ScRFOSJMZxXw-oYw@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div>Hi all,</div>
        <div><br>
        </div>
        <div>I wanted to give a quick update on the status of NPM for
          the IR optimization pipeline and ask some questions.</div>
        <div><br>
        </div>
        <div>In the past I believe there were thoughts that NPM was
          basically ready because all of check-llvm and check-clang
          passed when -DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=ON was
          specified. But that CMake flag did not apply to opt and any
          tests running something like `opt -foo-pass -bar-pass` (which
          is the vast majority of check-llvm tests) were still using the
          legacy PM. The intended way to use NPM was to use the -passes
          flag, e.g. `opt -passes='foo,bar'`.</div>
        <div><br>
        </div>
        <div>I've added a -enable-new-pm flag to opt to force running
          NPM passes even when `opt -foo-pass` is used. This is because
          I didn't want to go through every single test and figure out
          which ones should be using both -foo-pass and -passes=foo.
          Switching on -enable-new-pm currently leads to ~1800
          check-llvm failures. I've documented the failed tests count
          per directory in <a
            href="https://bugs.llvm.org/show_bug.cgi?id=46651"
            moz-do-not-send="true">https://bugs.llvm.org/show_bug.cgi?id=46651</a>
          (some have been fixed since that was posted).</div>
        <div><br>
        </div>
        <div>This has led to real bugs in NPM being discovered and fixed
          (e.g. some optnone issues).</div>
        <div><br>
        </div>
        <div>But a large portion of the remaining failures are because
          codegen-only passes haven't been ported to NPM yet. That's
          fine for the optimization pipeline NPM transition since it
          doesn't affect the optimization pipeline, but it does present
          an issue with the approach of the -enable-new-pm flag (which
          would by default become true alongside the NPM transition).
          Lots of tests are testing codegen-specific passes via opt
          (e.g. `opt -amdgpu-lower-intrinsics`) and they can't use NPM
          (yet).</div>
        <div><br>
        </div>
        <div>I was thinking either we have a way of identifying
          codegen-only passes and revert back to the legacy PM in opt
          whenever we see one, or we go back to considering
          the originally intended approach of adding an equivalent
          `-passes=` RUN to all tests that should be also running under
          NPM.</div>
        <div><br>
        </div>
        <div>I'm not sure of a nice and clean solution to identify
          codegen-only passes. We could go and update every instance of
          INITIALIZE_PASS to take another parameter indicating if it's
          codegen-only. Or we could just have a central list somewhere
          where we check if the pass is in some hardcoded list or has
          some prefix (e.g. "x86-").</div>
        <div><br>
        </div>
        <div>The approach of adding equivalent `-passes=` RUN lines to
          all relevant tests seems daunting, but not exactly sure how
          daunting. Maybe it's possible to script something and see what
          fails? We'd still need some way to identify codegen-only
          passes to make sure we don't miss anything, and we'd need to
          distinguish between analyses and normal passes. Also, it would
          slow down test execution since we'd run a lot more tests
          twice, but maybe that's not such a big deal? Maybe it's good
          to have most tests running against the legacy PM even when NPM
          is on by default?</div>
        <div><br>
        </div>
        <div>Thoughts?</div>
        <div><br>
        </div>
        This is split off from <a
          href="http://lists.llvm.org/pipermail/llvm-dev/2020-July/143395.html"
          target="_blank" moz-do-not-send="true">http://lists.llvm.org/pipermail/llvm-dev/2020-July/143395.html</a>.
        <div><br>
        </div>
        <div><br>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-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="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
    </blockquote>
  </body>
</html>