[llvm-dev] new pass manager version of opt vs. legacy pass manager version

[Arthur Eubanks via llvm-dev]

A small nit, please use `opt -passes=foo` rather than `opt -foo
-enable-new-pm` to run tests against the new PM. `-enable-new-pm` basically
attempts to rewrite `opt -foo` into `opt -passes=foo`, and the new PM
custom pass pipeline creation is designed around parsing the `-passes=`. At
some point `-enable-new-pm` should go away and all tests should use
`-passes=`.

On Thu, Apr 22, 2021 at 10:22 AM Philip Reames via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I ran across a case like this recently.  In that particular case, it was
> an IPO related test and the root issue was a difference in how the pass
> managers handled declarations in CGSCC passes.  (There was a discussion on
> llvm-dev on the topic if you're interested.)
>
> The practical takeaway is that certain tests needed -enable-new-pm
> explicitly set or disabled.  With the options parsing for (e.g.
> -function-attrs) implicitly selecting the currently enabled (in build
> config) pass manager, some tests need to be explicitly pinned to one.
>
> I would advocate for allowing -enable-new-pm=1 to be added to tests where
> relevant, and making no systematic attempt to keep all tests running on the
> old pm.  As mentioned already downthread, there will be an increasing class
> of behavior not supported on the new pm.
>
> I also think we should explicitly set of deprecation timeline for the old
> pm in the main pipeline, but that's a separate discussion.  I can't wait
> until the day we rename LegacyPM to CodeGenPM.  :)
>
> Philip
> On 4/22/21 8:33 AM, Snider, Todd via llvm-dev wrote:
>
> Hello All,
>
>
>
> My development group has been maintaining a downstream version of the
> monorepo that stays in sync with the upstream “main” branch, but we are
> still using the legacy pass manager in our local copy of the monorepo.
>
>
>
> We’ve recently encountered a few instances of lit tests that are failing
> when run with the legacy pass manager version of opt, but pass when run
> with the new pass manager version of opt.
>
>
>
> The situation raises a couple of questions:
>
>    - Is the legacy pass manager behavior being adequately tested by the
>    buildbots?
>    - What expectation should there be that legacy pass manager behavior
>    will be maintained in light of changes made to code that affects both the
>    new pass manager version and the legacy pass manager version of opt?
>
>
>
> I suspect that my group is not the only ones trying to stay in sync with
> the upstream LLVM main branch and keep using the legacy pass manager, and I
> anticipate the only long-term remedy for our situation is to move to using
> the new pass manager as soon as we can.
>
>
>
> Thoughts?
>
>
>
> Regards.
>
>
>
> Todd Snider
>
> Texas Instruments Incorporated
>
> _______________________________________________
> LLVM Developers mailing listllvm-dev at lists.llvm.orghttps://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/20210422/7f57a9c5/attachment.html>