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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210825/427aa30b/attachment.html>

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 listllvm-dev at
lists.llvm.orghttps://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/b15754e2/attachment.html>