llvm dev - Jan 2021 - [NewPM] Purpose of the 'opt' option '-enable-new-pm'

Is the 'opt' option '-enable-new-pm' intended to be used mostly
as a convenience for migrating lit-tests or is it actually intended to be a
built-in translation from generic legacy PM command lines into new PM
equivalents?

That is will '-enable-new-pm' be supported to the same level as
'-passes' as an interface for the new PM?

-Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210121/dcee0897/attachment.html>

`-enable-new-pm` is purely for the new PM transition, ideally at some point
it will disappear when all tests are using `-passes`. We'll have to do a
mass update of the lit tests at some point after the new PM transition,
probably when we start thinking about deprecating the legacy PM (at least
for the optimization pipeline).
(Also unrelated IMO having a `-passes` flag instead of specifying each pass
as its own flag is a lot cleaner)

On Thu, Jan 21, 2021 at 5:07 AM Markus Lavin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Is the ‘opt’ option ‘-enable-new-pm’ intended to be used mostly as a
> convenience for migrating lit-tests or is it actually intended to be a
> built-in translation from generic legacy PM command lines into new PM
> equivalents?
>
>
>
> That is will ‘-enable-new-pm’ be supported to the same level as ‘-passes’
> as an interface for the new PM?
>
>
>
> -Markus
> _______________________________________________
> 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/20210121/35bcd9b0/attachment.html>