<div dir="ltr">No problem, glad it got resolved.<div>And next time I should probably add more context to my llvm-dev posts.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Dec 5, 2020 at 1:38 PM Philip Reames <<a href="mailto:listmail@philipreames.com">listmail@philipreames.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <p>For anyone reading, please disregard all of my responses to this
      thread (especially this one).  As Mehdi was kind enough to point
      out downthread, I was misunderstanding the proposal from the
      beginning.</p>
    <p>Arthur, my apologies for utterly derailing a conversation and for
      not bothering to confirm I knew what I was talking about before
      doing so.</p>
    <p>Philip<br>
    </p>
    <div>On 12/4/20 2:18 PM, Philip Reames
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <p>I strongly disagree with this proposal.  As in, please do not
        land patches which implement this proposal.  If anything, we
        should remove the build time config flag entirely.  <br>
      </p>
      <p>The new manager is mature and has been in wide use for a long
        time now.  Moving it to a conditional compilation item is a
        major regression in implied maturity and completely
        unwarranted.  If anything, we should just flip the dang flag and
        make people using the old pass manager support it.  (Most
        downstream groups I know of are running NPM.)</p>
      <p>Philip<br>
      </p>
      <div>On 12/1/20 12:34 PM, Arthur Eubanks
        via llvm-dev wrote:<br>
      </div>
      <blockquote type="cite">
        
        <div dir="ltr">
          <div>The ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER CMake flag
            currently only affects Clang. It should probably also change
            all other uses of pass managers where possible.  <br>
          </div>
          <div><br>
          </div>
          <div>There are a couple of uses inside LLD for LTO which
            already have new/legacy PM flags and should probably look at
            ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER to determine the
            default. <a href="https://github.com/llvm/llvm-project/blob/1314a4938fba865412598b7227cb4657d59cd8bc/lld/wasm/Driver.cpp#L382" target="_blank">Some</a> <a href="https://github.com/llvm/llvm-project/blob/1314a4938fba865412598b7227cb4657d59cd8bc/llvm/include/llvm/LTO/Config.h#L53" target="_blank">examples</a>.</div>
          <div><br>
          </div>
          <div>Also at some point in the future when check-llvm has been
            fixed to work with opt's -enable-new-pm flag by default,
            that should also be dependent upon
            ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER.</div>
          <div><br>
          </div>
          <div>Any objections?</div>
        </div>
        <br>
        <fieldset></fieldset>
        <pre>_______________________________________________
LLVM Developers mailing list
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
      </blockquote>
    </blockquote>
  </div>

</blockquote></div>