<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"MS Gothic";
        panose-1:2 11 6 9 7 2 5 8 2 4;}
@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;}
@font-face
        {font-family:"\@MS Gothic";
        panose-1:2 11 6 9 7 2 5 8 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
span.EmailStyle21
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></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]-->
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Downstreams could be re-enabling the legacy pass manager in CMake. It’s still there, and still supported. If a downstream has made non-trivial changes to the pass pipeline for legacy pass manager, it’s going to be a ton of work to ensure
 performance parity when enabling new pass manager.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I think, if LLVM is built with LLVM_ENABLE_NEW_PASS_MANAGER set to OFF, then you should get a big scary warning at CMake configure time, but clang/opt should not complain. If LLVM is built with DLLVM_ENABLE_NEW_PASS_MANAGER set to ON, but
 the flag is passed to clang/opt to build using the legacy pass manager, you should get a warning from clang/opt.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In my opinion, if these deprecation warnings make it in for LLVM 13, then it’s fine to begin removing LPM in LLVM 14.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">thanks,<o:p></o:p></p>
<p class="MsoNormal">   Chris Tetreault<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Arthur Eubanks <aeubanks@google.com> <br>
<b>Sent:</b> Tuesday, August 24, 2021 1:47 PM<br>
<b>To:</b> Fāng-ruì Sòng <maskray@google.com><br>
<b>Cc:</b> Chris Tetreault <ctetreau@quicinc.com>; llvm-dev@lists.llvm.org; Tom Stellard <tstellar@redhat.com><br>
<b>Subject:</b> Re: [llvm-dev] [RFC] Deprecating the legacy pass manager for the optimization pipeline<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p align="center" style="text-align:center"><strong><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:black;background:yellow">WARNING:</span></strong><span style="font-size:10.5pt;font-family:"Arial",sans-serif;color:black;background:yellow">
 This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.</span><o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">If nobody is setting -DLLVM_ENABLE_NEW_PASS_MANAGER=off then I'm not sure that we need to go through the whole deprecation dance. Is there anybody doing that?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">But if we do the deprecation dance, should it be a CMake warning or a clang warning? I'm not sure people will notice a CMake warning.
<o:p></o:p></p>
<div>
<p class="MsoNormal">And would putting that in the 13.x branch be good enough to start removing after 14.x?<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Tue, Aug 24, 2021 at 12:26 PM Fāng-ruì Sòng <<a href="mailto:maskray@google.com">maskray@google.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">On Tue, Aug 24, 2021 at 12:21 PM Chris Tetreault <<a href="mailto:ctetreau@quicinc.com" target="_blank">ctetreau@quicinc.com</a>> wrote:<br>
><br>
> Since deprecating something is giving warning that it’s going to be removed, I don’t think it’s fair to deprecate and remove in one step. If legacy pass manager isn’t currently formally deprecated (as in, loudly complains when you try to use it), then I’d
 personally like to see it deprecated for a release before any steps to completely remove it are taken.<br>
<br>
I just wanted to say the same thing:)<br>
<br>
I don't mind that we install a warning for -DLLVM_ENABLE_NEW_PASS_MANAGER=off<br>
in the release/13.x branch so that the signal is clearer to downstream users.<br>
<br>
> From: llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>> On Behalf Of Arthur Eubanks via llvm-dev<br>
> Sent: Tuesday, August 24, 2021 12:10 PM<br>
> To: Fangrui Song <<a href="mailto:maskray@google.com" target="_blank">maskray@google.com</a>><br>
> Cc: llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
> Subject: Re: [llvm-dev] [RFC] Deprecating the legacy pass manager for the optimization pipeline<br>
><br>
><br>
><br>
> WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.<br>
><br>
> I probably should have said "deprecating and removing".<br>
><br>
><br>
><br>
> My intention was to remove it completely. -DLLVM_ENABLE_NEW_PASS_MANAGER wouldn't do anything and we'd remove the -flegacy-pass-manaager/-fexperimental-new-pass-manager flags, as well as the corresponding lld flags.<br>
><br>
><br>
><br>
> On Tue, Aug 24, 2021 at 12:02 PM Fangrui Song <<a href="mailto:maskray@google.com" target="_blank">maskray@google.com</a>> wrote:<br>
><br>
> On 2021-08-24, Arthur Eubanks via llvm-dev wrote:<br>
> >The new pass manager has been on by default since the 13 branch. Now that<br>
> >we've branched for 14, I'd like to start the process of deprecating and<br>
> >removing legacy pass manager support for the optimization pipeline. This<br>
> >includes clang, opt, and lld LTO support.<br>
> ><br>
> >Note that this doesn't apply to the codegen pipeline since there's no new<br>
> >pass manager support for that yet.<br>
> ><br>
> >Are there any objections?<br>
><br>
> "deprecating" and 'removing" are different.<br>
><br>
> For 14.0.0, do you plan that -DLLVM_ENABLE_NEW_PASS_MANAGER=off will<br>
> give a warning or will be completely unsupported?<br>
<br>
<br>
<br>
-- <br>
<span style="font-family:"MS Gothic"">宋方睿</span><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</body>
</html>