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

Now with llvm-dev as receiver (thanks to Chris T for noticing the mistake).

-----Original Message-----
From: Björn Pettersson A 
Sent: den 25 augusti 2021 16:26
To: Fāng-ruì Sòng <maskray at google.com>; Chris Tetreault <ctetreau at
quicinc.com>
Subject: RE: [llvm-dev] [RFC] Deprecating the legacy pass manager for the
optimization pipeline
> -----Original Message-----
> From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of
Fang-ruì Sòng
> via llvm-dev
> Sent: den 25 augusti 2021 01:53
> To: Chris Tetreault <ctetreau at quicinc.com>
> Cc: llvm-dev at lists.llvm.org
> Subject: Re: [llvm-dev] [RFC] Deprecating the legacy pass manager for the
> optimization pipeline
> 
> On 2021-08-24, Chris Tetreault wrote:
> >Let me clarify that when I say “it’s fine to begin removing LPM in LLVM
> 14”, I mean that it’s fine to begin removing LPM once LLVM 14 is released,
> and the version string in main is set to 15.
> 
> While I think such a deprecation and removal policy may be fine for many
> non-trivial things, asking
> this may be too much for the pass manager. With a grain of salt,
> "downstreams are on their own." New
> PM migration and legacy PM removal has been repeatedly forewarned.  I think
> llvm-project has done
> above and beyond what it was expected.  The flip in git was done in
> February.
> 
> After 13.0.0 is released for, say 2 months, which additional attests its
> robustness, I think
> removing non-codegen legacy PM pieces should be fine.
> 
Yes, since there are codegen passes using legacy PM we can't just removing
everything.

But maybe we can start cleaning up some things, such as:

a) Removing impact of LLVM_ENABLE_NEW_PASS_MANAGER on -enable-new-pm in opt.
   Thus, making new-pm the default in opt (not depending on cmake config).
   For testing with opt and legacy PM one would need an explicit
-enable-new-pm=0.
   (One impact of this is that lots of lit tests using opt would run the
   new-PM version of the pass all the time. But for most tests, e.g. using
   a single pass, the implementation in the pass should be independent
   of the pass manager so that should hopefully not be a big loss.)

b) Given (a) we could start to clean up lit tests that run opt to use
   -passes syntax.

c) Removing support for using the legacy syntax for specifying passes to
   run in opt unless using -enable-new-pm=0.

d) Maybe we can remove the LLVM_ENABLE_NEW_PASS_MANAGER and
   ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER completely. Forcing anyone that
   still wants to use the legacy PM to use options such as
   -flegacy-pass-manager and -enable-new-pm=0 rather than allowing
   to build with different defaults.

The cleanups listed above are not really removing support for legacy PM,
it just starts to remove some of the compatibility hacks that has been
used to simplify the pass manager switch.

/Björn

PS. The things I mention above has been really helpful when doing the
migration to new-PM. If there still are project that haven't migrated,
then I understand that it might be harmful if we start cleaning up those
things. Although, I think that there have been lots of discussions and
RFC:s about the deprecation (and that one could expect cleanup to start
after the LLVM 13 branch out). The best way to find out if someone
still use things like LLVM_ENABLE_NEW_PASS_MANAGER could perhaps be by
try to remove it (and then if someone objects we can revert that patch
again).