[llvm-dev] [RFC] Deprecating the legacy pass manager for the optimization pipeline

[Mehdi AMINI via llvm-dev]

These revisions are deprecating (IIUC):
1) Clang user flags to use the legacy pass manager.
2) The CMake build flag that defines the *default* pass manager.

These don't seem like the most impactful for downstream users, are they?

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?

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.

Thanks,

-- 
Mehdi


On Fri, Aug 27, 2021 at 1:44 PM Chris Tetreault via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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.
>
>
>
> Thanks,
>
>    Chris Tetreault
>
>
>
> *From:* Arthur Eubanks <aeubanks at google.com>
> *Sent:* Friday, August 27, 2021 12:42 PM
> *To:* Chris Tetreault <ctetreau at quicinc.com>
> *Cc:* llvm-dev <llvm-dev at lists.llvm.org>
> *Subject:* Re: [llvm-dev] [RFC] Deprecating the legacy pass manager for
> the optimization pipeline
>
>
>
> *WARNING:* This email originated from outside of Qualcomm. Please be wary
> of any links or attachments, and do not enable macros.
>
> Are https://reviews.llvm.org/D108789 and https://reviews.llvm.org/D108775
> sufficient if we cherrypick them into 13?
>
>
>
> On Wed, Aug 25, 2021 at 11:22 AM Philip Reames <listmail at philipreames.com>
> wrote:
>
> 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.
>
> 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".
>
> 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.
>
> Philip
>
> 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.
>
> On 8/24/21 10:44 AM, Arthur Eubanks via llvm-dev wrote:
>
> 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.
>
>
>
> Note that this doesn't apply to the codegen pipeline since there's no new
> pass manager support for that yet.
>
>
>
> Are there any objections?
>
>
>
> _______________________________________________
>
> LLVM Developers mailing list
>
> llvm-dev at lists.llvm.org
>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210827/b121b00b/attachment.html>