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

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 
> <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
> 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/20210705/9e2ec21b/attachment.html>

`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>
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 listllvm-dev at
lists.llvm.orghttps://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/20210707/0e1999f9/attachment.html>