<div dir="ltr"><div>What legacy PM stuff I'd like to remove soonish:</div><div><br></div><div>1) Support for the CMake flag DLLVM_ENABLE_NEW_PASS_MANAGER=off (which is related to defaults for the next 3 items)<br></div><div>2) LTO support in various linkers<br></div><div>3) Clang support for the optimization pipeline</div><div>4) opt support for translating `-instcombine` into `-passes=instcombine`, will require updating many tests</div><div>5) PassManagerBuilder for building an optimization pipeline with the legacy PM (requires all of the above to be done first)</div><div><br></div><div>I can add these to the 13.x release notes.</div><div><br></div><div>If there are any existing users right now who continuously test against LLVM trunk and would like some time to port legacy PM passes to the new PM I'm happy to wait a couple of weeks/a month (and happy to answer any questions), but otherwise we shouldn't worry about downstream users who don't speak up. Porting most passes is generally pretty quick and easy, but some passes can be tricky.</div><div>As mentioned earlier, having two ways to do something can result in confusion upstream when debugging issues. And code cleanup is nice. Also, a fair number of lit tests currently run against both pass managers and removing some RUN lines against the legacy PM can speed up tests.</div><div><br></div><div><br></div><div>What won't be removed anytime soon:</div><div>1) General legacy PM infrastructure, such as llvm::legacy::PassManager, since codegen still uses it</div><div>2) Most legacy passes, since some IR passes run as part of the codegen pipeline (although no reason to keep around some legacy passes like LTO-specific passes)</div><div>        Some backends, via TargetPassConfig::addIRPasses(), will add various passes to the codegen IR pipeline.</div><div>3) Testing legacy passes via opt, since again some IR passes run as part of the codegen pipeline</div><div>        However, I'd like to explicitly enumerate all the passes that we allow opt to run under the legacy PM. For example, target-specific codegen IR passes like "amdgpu-lower-ctor-dtor" should be run under the legacy PM via `opt -amdgpu-lower-ctor-dtor`. But most passes like instcombine should only be invokable via the `opt -passes=instcombine` syntax so that we don't have to worry about people testing the wrong pass manager by using the wrong syntax. Even if some passes like instcombine are added to the codegen pipeline in a legacy pass manager, I don't think the confusion of `opt -instcombine` vs `opt -passes=instcombine` is worth the test coverage we may gain by being able to run instcombine with the legacy PM. Perhaps if we find that some passes do regress only under the legacy PM and not the new PM we can revisit this point.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Aug 27, 2021 at 6:17 PM Fāng-ruì Sòng <<a href="mailto:maskray@google.com" target="_blank">maskray@google.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">On Fri, Aug 27, 2021 at 3:55 PM Mehdi AMINI via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> These revisions are deprecating (IIUC):<br>
> 1) Clang user flags to use the legacy pass manager.<br>
> 2) The CMake build flag that defines the *default* pass manager.<br>
><br>
> These don't seem like the most impactful for downstream users, are they?<br>
<br>
The previous disabling mechanism<br>
-DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=off is ignored in main and<br>
release/13.x.<br>
If a user switches (-DLLVM_ENABLE_NEW_PASS_MANAGER=off), they should<br>
notice the warning.<br>
<br>
So I think we don't need something like<br>
-DLLVM_FORCE_USE_OLD_TOOLCHAIN=on which was done in 2019 to bump the<br>
toolchain requirement.<br>
<br>
> On the other hand, what seems to me to be critical to clarify is if you also intend to deprecate other things, like the use of the legacy pass manager in opt (or as a pass manager in a downstream tool/compiler)? Are we gonna also remove all the legacy adapters that make the passes work in the legacy pass manager as well?<br>
><br>
> This looks more important to me because this affects directly how other compilers are built on top of LLVM and push them to migrate, while the deprecation revision you sent may just have no effect on them.<br>
><br>
> Thanks,<br>
><br>
> --<br>
> Mehdi<br>
><br>
><br>
> On Fri, Aug 27, 2021 at 1:44 PM Chris Tetreault via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> I think that’s a sufficiently obnoxious warning. I still strongly prefer that no removals of functionality come until we branch for LLVM 14, but I think this will do for a notice of deprecation.<br>
>><br>
>><br>
>><br>
>> Thanks,<br>
>><br>
>>    Chris Tetreault<br>
>><br>
>><br>
>><br>
>> From: Arthur Eubanks <<a href="mailto:aeubanks@google.com" target="_blank">aeubanks@google.com</a>><br>
>> Sent: Friday, August 27, 2021 12:42 PM<br>
>> To: Chris Tetreault <<a href="mailto:ctetreau@quicinc.com" target="_blank">ctetreau@quicinc.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>
>> Are <a href="https://reviews.llvm.org/D108789" rel="noreferrer" target="_blank">https://reviews.llvm.org/D108789</a> and <a href="https://reviews.llvm.org/D108775" rel="noreferrer" target="_blank">https://reviews.llvm.org/D108775</a> sufficient if we cherrypick them into 13?<br>
>><br>
>><br>
>><br>
>> On Wed, Aug 25, 2021 at 11:22 AM Philip Reames <<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>> wrote:<br>
>><br>
>> I'd vote for immediate removal.  I don't have much sympathy for downstream consumers who haven't moved.  This effort has been underway for literal years.  Many - though not by any means all - downstream projects moved *before* upstream finally switched.  Let's put a nail in this coffin, and remove code aggressively.<br>
>><br>
>> Supporting both has serious ongoing costs.  As a real example, I have twice spent time in the last two weeks tracking down some odd quirk of the unrolling implementation to find it supports some quirk of the legacy pass. That slows down development, compromises quality, and is generally a "bad thing".<br>
>><br>
>> We might want to wait a couple of weeks/months to ensure stability, but we should only consider the needs to the upstream project itself when doing so.  Giving downstream projects time to react should be an explicit non-goal.<br>
>><br>
>> Philip<br>
>><br>
>> p.s. I don't expect this to be the actual decision reached, but since I only see opinions down-thread arguing for migration windows, I wanted to make a point of sharing the opposite opinion.  Fair warning, I probably won't reply to this thread further.  I don't have sufficient interest in the topic to make it worthwhile.<br>
>><br>
>> On 8/24/21 10:44 AM, Arthur Eubanks via llvm-dev wrote:<br>
>><br>
>> The new pass manager has been on by default since the 13 branch. Now that we've branched for 14, I'd like to start the process of deprecating and removing legacy pass manager support for the optimization pipeline. This includes clang, opt, and lld LTO support.<br>
>><br>
>><br>
>><br>
>> Note that this doesn't apply to the codegen pipeline since there's no new pass manager support for that yet.<br>
>><br>
>><br>
>><br>
>> Are there any objections?<br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>><br>
>> LLVM Developers mailing list<br>
>><br>
>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>><br>
>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
>><br>
>> _______________________________________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br>
<br>
<br>
-- <br>
宋方睿<br>
</blockquote></div>