<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html;
      charset=windows-1252">
  </head>
  <body>
    <p>I ran across a case like this recently.  In that particular case,
      it was an IPO related test and the root issue was a difference in
      how the pass managers handled declarations in CGSCC passes. 
      (There was a discussion on llvm-dev on the topic if you're
      interested.)</p>
    <p>The practical takeaway is that certain tests needed
      -enable-new-pm explicitly set or disabled.  With the options
      parsing for (e.g. -function-attrs) implicitly selecting the
      currently enabled (in build config) pass manager, some tests need
      to be explicitly pinned to one.  <br>
    </p>
    <p>I would advocate for allowing -enable-new-pm=1 to be added to
      tests where relevant, and making no systematic attempt to keep all
      tests running on the old pm.  As mentioned already downthread,
      there will be an increasing class of behavior not supported on the
      new pm.</p>
    <p>I also think we should explicitly set of deprecation timeline for
      the old pm in the main pipeline, but that's a separate
      discussion.  I can't wait until the day we rename LegacyPM to
      CodeGenPM.  :)</p>
    <p>Philip<br>
    </p>
    <div class="moz-cite-prefix">On 4/22/21 8:33 AM, Snider, Todd via
      llvm-dev wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:d2e98ea1cd414995bf413bd25d14e79f@ti.com">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <meta name="Generator" content="Microsoft Word 15 (filtered
        medium)">
      <style>@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}.MsoChpDefault
        {mso-style-type:export-only;}div.WordSection1
        {page:WordSection1;}ol
        {margin-bottom:0in;}ul
        {margin-bottom:0in;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal">Hello All,<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">My development group has been maintaining a
          downstream version of the monorepo that stays in sync with the
          upstream “main” branch, but we are still using the legacy pass
          manager in our local copy of the monorepo.<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">We’ve recently encountered a few instances
          of lit tests that are failing when run with the legacy pass
          manager version of opt, but pass when run with the new pass
          manager version of opt.<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">The situation raises a couple of questions:<o:p></o:p></p>
        <ul style="margin-top:0in" type="disc">
          <li class="MsoNormal" style="mso-list:l0 level1 lfo1">Is the
            legacy pass manager behavior being adequately tested by the
            buildbots?<o:p></o:p></li>
          <li class="MsoNormal" style="mso-list:l0 level1 lfo1">What
            expectation should there be that legacy pass manager
            behavior will be maintained in light of changes made to code
            that affects both the new pass manager version and the
            legacy pass manager version of opt?<o:p></o:p></li>
        </ul>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">I suspect that my group is not the only
          ones trying to stay in sync with the upstream LLVM main branch
          and keep using the legacy pass manager, and I anticipate the
          only long-term remedy for our situation is to move to using
          the new pass manager as soon as we can.<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">Thoughts?<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">Regards.<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">Todd Snider<o:p></o:p></p>
        <p class="MsoNormal">Texas Instruments Incorporated<o:p></o:p></p>
      </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>