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

[Johannes Doerfert via llvm-dev]

On 4/22/21 12:22 PM, Philip Reames via llvm-dev 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.  :)

+1 for these ideas, after addressing the comment by Arthur. This is 
better than XFAIL: old-PM for sure.
We can add `-passes=` to those tests to force the new-PM and go on 
without requiring feature parity.

I also would love a deprecation timeline.

~ Johannes


>
> 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
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev