[llvm-dev] [RFC][NewPM] Migrating tests from `opt -foo` to `opt -passes=foo`

Mon Aug 23 04:22:02 PDT 2021

I’ve created a patch to show-case the intended migration suggested by this RFC: https://reviews.llvm.org/D108472

Although, I think the timeline that has been discussed was that we should send out some kind of deprecation announcement before doing this. And maybe also remove the ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER cmake option first.

/Björn

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Arthur Eubanks via llvm-dev
Sent: den 7 juli 2021 19:50
To: Philip Reames <listmail at philipreames.com>
Cc: llvm-dev <llvm-dev at lists.llvm.org>
Subject: Re: [llvm-dev] [RFC][NewPM] Migrating tests from `opt -foo` to `opt -passes=foo`

`opt -pass` relies on the global registry of legacy passes, which we should really get rid of at some point. It might be possible to do something similar with a cl::opt that uses the new PM PassBuilder parsing, but that would end up being super hacky. `opt -pass` doesn't really fit the design of the new PM.

IMO `opt -passes=foo` is much clearer than `opt -foo` and is not much longer to type (it's what I use now, even for simple things). I remember when I started working on LLVM, the `opt -foo` syntax was confusing, especially when there were multiple passes and they were interleaved on the command line with other flags.

On Mon, Jul 5, 2021 at 10:56 AM Philip Reames <listmail at philipreames.com<mailto:listmail at philipreames.com>> wrote:

Can I ask a basic question?  Given we've separated the interface from the choice of pass manager, why are we removing the "-pass" interface at all?  Is there some non-trivial amount of maintenance needed to keep that working?

Personally, I find the -pass-name interface much easier to work with for simple adhoc testing than the -passes version.

I can definitely see the case for dropping testing of old-pm + pass combinations, but at this point, that's less about the command line and more about removing -enable-new-pm=0 tests.  There's also maybe an argument that we should spell the command line only one way in testing, but that's different than removing the command line parsing.

Philip
On 6/28/21 6:33 PM, Arthur Eubanks via llvm-dev wrote:
Now that the new PM has been the default for the optimization pipeline for a while, I'd like to start thinking about next steps. Not quite deprecating the legacy PM for the optimization pipeline yet, since we should wait for the next LLVM release. But one thing we can start doing is cleaning up lit tests that use opt.

There's been confusion over exactly how the -passes= parsing works, so I've updated https://llvm.org/docs/NewPassManager.html (or rather just the sources, seems like the webpage hasn't updated yet) with some details.

For background, `opt -foo` is currently already translated to `opt -passes=foo` when the new PM is on (which is true by default).

I imagine this would be a short script that has a list of passes from PassRegistry.def and the IR unit they operate on, and looks through RUN lines with opt, deleting existing pass arguments and replacing them with a -passes= argument. If we have more than one pass, each pass would be wrapped in the proper adaptor.  For example, `opt -instcombine -globaldce` becomes `opt -passes='function(instcombine),globaldce'`.

We need to make sure that we don't end up causing too many duplicate RUN lines if we have tests that specify both `opt -foo` and `opt -passes=foo`.

We should wait until the next LLVM release before changing all opt tests since we do want any bots using the legacy PM to still run opt tests against the legacy PM. But until then we can pick a couple lesser-used passes/test directories to touch up.

Note that this does not include any opt tests that test passes on available under the legacy PM, which would be IR passes in the codegen pipeline.

_______________________________________________

LLVM Developers mailing list

llvm-dev at lists.llvm.org<mailto: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/20210823/1c2b6ace/attachment.html>