[llvm-dev] Renaming passes

Arthur Eubanks via llvm-dev llvm-dev at lists.llvm.org
Fri Jun 26 10:59:03 PDT 2020


On Fri, Jun 26, 2020 at 9:19 AM Hiroshi Yamauchi <yamauchi at google.com>
wrote:

>
>
> On Thu, Jun 25, 2020 at 9:48 AM Arthur Eubanks <aeubanks at google.com>
> wrote:
>
>> After talking with some NPM people, I believe the ultimate goal after NPM
>> is enabled by default is to only support `-passes=`, and remove support for
>> `-foo-pass`.
>> However, until NPM is enabled by default, we still want tests using opt
>> to use the legacy PM by default.
>> We could attempt to make `-passes=` work with the legacy PM and have a
>> legacy vs new PM flag, but given the design/syntax of `-passes=` I don't
>> think that's feasible (see llvm/include/llvm/Passes/PassBuilder.h).
>> So for making sure everything works with NPM, I think we need to support
>> `-foo-pass` in NPM to be able to run all opt tests against NPM. Then at
>> some point after NPM is enabled by default we can attempt to migrate
>> everything to `-passes=`.
>>
>
> I think many (but not all) test .ll files already have multiple RUN lines
> to run with both pass managers. If we do it in every test .ll file, would
> that work during the transition?
>

I don't think that's much less work than supporting `-foo-pass`, we still
have to port all the passes to NPM. The infra for supporting `-foo-pass` is
already done (I hope at least) and it reuses the same
PassBuilder.parsePassPipeline() interface as `-passes=`. The only extra
effort required is making sure pass names match up between the two pass
managers.

And if we do go with adding `-passes=` to all tests and letting `-foo-pass`
run under the legacy PM, then we're sort of saying that everybody should
migrate to `-passes=` since otherwise the test would be testing the legacy
PM after the NPM switch, and that test's value is diminished. As mentioned
before this is a possibility, but a separate concern.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200626/ae49b893/attachment.html>


More information about the llvm-dev mailing list