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

[Philip Reames via llvm-dev]

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 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/091c1c9e/attachment.html>