llvm dev - Jul 2020 - New pass manager for optimization pipeline status and questions

Hi all,

I wanted to give a quick update on the status of NPM for the IR
optimization pipeline and ask some questions.

In the past I believe there were thoughts that NPM was basically ready
because all of check-llvm and check-clang passed when
-DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=ON was specified. But that CMake
flag did not apply to opt and any tests running something like `opt
-foo-pass -bar-pass` (which is the vast majority of check-llvm tests) were
still using the legacy PM. The intended way to use NPM was to use the
-passes flag, e.g. `opt -passes='foo,bar'`.

I've added a -enable-new-pm flag to opt to force running NPM passes even
when `opt -foo-pass` is used. This is because I didn't want to go through
every single test and figure out which ones should be using both -foo-pass
and -passes=foo. Switching on -enable-new-pm currently leads to ~1800
check-llvm failures. I've documented the failed tests count per directory
in https://bugs.llvm.org/show_bug.cgi?id=46651 (some have been fixed since
that was posted).

This has led to real bugs in NPM being discovered and fixed (e.g. some
optnone issues).

But a large portion of the remaining failures are because codegen-only
passes haven't been ported to NPM yet. That's fine for the optimization
pipeline NPM transition since it doesn't affect the optimization pipeline,
but it does present an issue with the approach of the -enable-new-pm flag
(which would by default become true alongside the NPM transition). Lots of
tests are testing codegen-specific passes via opt (e.g. `opt
-amdgpu-lower-intrinsics`) and they can't use NPM (yet).

I was thinking either we have a way of identifying codegen-only passes and
revert back to the legacy PM in opt whenever we see one, or we go back to
considering the originally intended approach of adding an equivalent
`-passes=` RUN to all tests that should be also running under NPM.

I'm not sure of a nice and clean solution to identify codegen-only passes.
We could go and update every instance of INITIALIZE_PASS to take another
parameter indicating if it's codegen-only. Or we could just have a central
list somewhere where we check if the pass is in some hardcoded list or has
some prefix (e.g. "x86-").

The approach of adding equivalent `-passes=` RUN lines to all relevant
tests seems daunting, but not exactly sure how daunting. Maybe it's
possible to script something and see what fails? We'd still need some way
to identify codegen-only passes to make sure we don't miss anything, and
we'd need to distinguish between analyses and normal passes. Also, it would
slow down test execution since we'd run a lot more tests twice, but maybe
that's not such a big deal? Maybe it's good to have most tests running
against the legacy PM even when NPM is on by default?

Thoughts?

This is split off from
http://lists.llvm.org/pipermail/llvm-dev/2020-July/143395.html.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200722/1e74b2d7/attachment.html>

(I'm probably going to derail your thread, sorry about that.)

I think at this point, we should just bite the bullet and make the 
switch to NPM by default for Clang's optimization pipeline. Today.

Why?  Because many of our downstream consumers have already switched.  
Google has.  We (Azul) have.  I think I've heard the same for a couple 
other major contributors.  Why does this matter?  Testing.  At the 
current moment, the vast majority of testing the project gets is 
exercising NPM, not LPM.

NPM is functionally complete for Clang optimization.  There might be a 
few missing cases around the sanitizers, but last I heard those were on 
the edge of being fixed.

I think we should make the switch, and deal with any fall out as 
regressions.  If we made the change immediately after a release branch, 
we'd have several months to address any major issues before the next 
release.

Philip

On 7/22/20 2:39 PM, Arthur Eubanks via llvm-dev wrote:
> Hi all,
>
> I wanted to give a quick update on the status of NPM for the IR 
> optimization pipeline and ask some questions.
>
> In the past I believe there were thoughts that NPM was basically ready 
> because all of check-llvm and check-clang passed when 
> -DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=ON was specified. But that 
> CMake flag did not apply to opt and any tests running something like 
> `opt -foo-pass -bar-pass` (which is the vast majority of check-llvm 
> tests) were still using the legacy PM. The intended way to use NPM was 
> to use the -passes flag, e.g. `opt -passes='foo,bar'`.
>
> I've added a -enable-new-pm flag to opt to force running NPM passes 
> even when `opt -foo-pass` is used. This is because I didn't want to go 
> through every single test and figure out which ones should be using 
> both -foo-pass and -passes=foo. Switching on -enable-new-pm currently 
> leads to ~1800 check-llvm failures. I've documented the failed tests 
> count per directory in https://bugs.llvm.org/show_bug.cgi?id=46651 
> (some have been fixed since that was posted).
>
> This has led to real bugs in NPM being discovered and fixed (e.g. some 
> optnone issues).
>
> But a large portion of the remaining failures are because codegen-only 
> passes haven't been ported to NPM yet. That's fine for the 
> optimization pipeline NPM transition since it doesn't affect the 
> optimization pipeline, but it does present an issue with the approach 
> of the -enable-new-pm flag (which would by default become true 
> alongside the NPM transition). Lots of tests are testing 
> codegen-specific passes via opt (e.g. `opt -amdgpu-lower-intrinsics`) 
> and they can't use NPM (yet).
>
> I was thinking either we have a way of identifying codegen-only passes 
> and revert back to the legacy PM in opt whenever we see one, or we go 
> back to considering the originally intended approach of adding an 
> equivalent `-passes=` RUN to all tests that should be also running 
> under NPM.
>
> I'm not sure of a nice and clean solution to identify codegen-only 
> passes. We could go and update every instance of INITIALIZE_PASS to 
> take another parameter indicating if it's codegen-only. Or we could 
> just have a central list somewhere where we check if the pass is in 
> some hardcoded list or has some prefix (e.g. "x86-").
>
> The approach of adding equivalent `-passes=` RUN lines to all relevant 
> tests seems daunting, but not exactly sure how daunting. Maybe it's 
> possible to script something and see what fails? We'd still need some 
> way to identify codegen-only passes to make sure we don't miss 
> anything, and we'd need to distinguish between analyses and normal 
> passes. Also, it would slow down test execution since we'd run a lot 
> more tests twice, but maybe that's not such a big deal? Maybe it's 
> good to have most tests running against the legacy PM even when NPM is 
> on by default?
>
> Thoughts?
>
> This is split off from 
> http://lists.llvm.org/pipermail/llvm-dev/2020-July/143395.html.
>
>
>
> _______________________________________________
> 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/20200722/18a68913/attachment.html>

From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Arthur
Eubanks via llvm-dev
Sent: Wednesday, July 22, 2020 2:39 PM
To: llvm-dev <llvm-dev at lists.llvm.org>
Subject: [llvm-dev] New pass manager for optimization pipeline status and
questions

Hi all,

I wanted to give a quick update on the status of NPM for the IR optimization
pipeline and ask some questions.

In the past I believe there were thoughts that NPM was basically ready because
all of check-llvm and check-clang passed when
-DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=ON was specified. But that CMake flag did
not apply to opt and any tests running something like `opt -foo-pass -bar-pass`
(which is the vast majority of check-llvm tests) were still using the legacy PM.
The intended way to use NPM was to use the -passes flag, e.g. `opt
-passes='foo,bar'`.

I've added a -enable-new-pm flag to opt to force running NPM passes even
when `opt -foo-pass` is used. This is because I didn't want to go through
every single test and figure out which ones should be using both -foo-pass and
-passes=foo. Switching on -enable-new-pm currently leads to ~1800 check-llvm
failures. I've documented the failed tests count per directory in
https://bugs.llvm.org/show_bug.cgi?id=46651 (some have been fixed since that was
posted).

This has led to real bugs in NPM being discovered and fixed (e.g. some optnone
issues).

But a large portion of the remaining failures are because codegen-only passes
haven't been ported to NPM yet. That's fine for the optimization
pipeline NPM transition since it doesn't affect the optimization pipeline,
but it does present an issue with the approach of the -enable-new-pm flag (which
would by default become true alongside the NPM transition). Lots of tests are
testing codegen-specific passes via opt (e.g. `opt -amdgpu-lower-intrinsics`)
and they can't use NPM (yet).

I think the ideal way is just to port these to NPM. The problem is if the opt
pipeline NPM switch is blocked on this, we’re forcing the targets to start
porting which I’m not sure if target owners want to do.
On the other end, we’re (almost) actually ready to make these target IR passes
use NPM for testing purpose with `opt` tool. Except there needs a way to expose
these passes through llvm/lib/Target, llvm/lib/CodeGen rather than
llvm/lib/Passes to `opt`. As part of the codegen using NPM work, this is almost
done.

I was thinking either we have a way of identifying codegen-only passes and
revert back to the legacy PM in opt whenever we see one, or we go back to
considering the originally intended approach of adding an equivalent `-passes=`
RUN to all tests that should be also running under NPM.

I would prefer the former since it sounds less pervasive.

I'm not sure of a nice and clean solution to identify codegen-only passes.
We could go and update every instance of INITIALIZE_PASS to take another
parameter indicating if it's codegen-only. Or we could just have a central
list somewhere where we check if the pass is in some hardcoded list or has some
prefix (e.g. "x86-").

The latter seems in line with the progress has been made on codegen using NPM
work where each target would maintain their own pass registry like
PassRegister.def. For x86, it is (tentatively) called X86PassRegistry.def.
(https://reviews.llvm.org/D83613). If It is useful for the opt pipeline NPM
switch, we could find a way to factor it out.

The approach of adding equivalent `-passes=` RUN lines to all relevant tests
seems daunting, but not exactly sure how daunting. Maybe it's possible to
script something and see what fails? We'd still need some way to identify
codegen-only passes to make sure we don't miss anything, and we'd need
to distinguish between analyses and normal passes. Also, it would slow down test
execution since we'd run a lot more tests twice, but maybe that's not
such a big deal? Maybe it's good to have most tests running against the
legacy PM even when NPM is on by default?

Thoughts?

This is split off from
http://lists.llvm.org/pipermail/llvm-dev/2020-July/143395.html.


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200722/4a82b120/attachment-0001.html>

FWIW I'm in favor of this direction while making sure that we keep focus on
removing the vestiges of the old pass manager for the code health impact to
the project.

-eric

On Wed, Jul 22, 2020 at 3:15 PM Philip Reames via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> (I'm probably going to derail your thread, sorry about that.)
>
> I think at this point, we should just bite the bullet and make the switch
> to NPM by default for Clang's optimization pipeline.  Today.
>
> Why?  Because many of our downstream consumers have already switched.
> Google has.  We (Azul) have.  I think I've heard the same for a couple
> other major contributors.  Why does this matter?  Testing.  At the current
> moment, the vast majority of testing the project gets is exercising NPM,
> not LPM.
>
> NPM is functionally complete for Clang optimization.  There might be a few
> missing cases around the sanitizers, but last I heard those were on the
> edge of being fixed.
>
> I think we should make the switch, and deal with any fall out as
> regressions.  If we made the change immediately after a release branch,
> we'd have several months to address any major issues before the next
> release.
>
> Philip
> On 7/22/20 2:39 PM, Arthur Eubanks via llvm-dev wrote:
>
> Hi all,
>
> I wanted to give a quick update on the status of NPM for the IR
> optimization pipeline and ask some questions.
>
> In the past I believe there were thoughts that NPM was basically ready
> because all of check-llvm and check-clang passed when
> -DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=ON was specified. But that CMake
> flag did not apply to opt and any tests running something like `opt
> -foo-pass -bar-pass` (which is the vast majority of check-llvm tests) were
> still using the legacy PM. The intended way to use NPM was to use the
> -passes flag, e.g. `opt -passes='foo,bar'`.
>
> I've added a -enable-new-pm flag to opt to force running NPM passes
even
> when `opt -foo-pass` is used. This is because I didn't want to go
through
> every single test and figure out which ones should be using both -foo-pass
> and -passes=foo. Switching on -enable-new-pm currently leads to ~1800
> check-llvm failures. I've documented the failed tests count per
directory
> in https://bugs.llvm.org/show_bug.cgi?id=46651 (some have been fixed
> since that was posted).
>
> This has led to real bugs in NPM being discovered and fixed (e.g. some
> optnone issues).
>
> But a large portion of the remaining failures are because codegen-only
> passes haven't been ported to NPM yet. That's fine for the
optimization
> pipeline NPM transition since it doesn't affect the optimization
pipeline,
> but it does present an issue with the approach of the -enable-new-pm flag
> (which would by default become true alongside the NPM transition). Lots of
> tests are testing codegen-specific passes via opt (e.g. `opt
> -amdgpu-lower-intrinsics`) and they can't use NPM (yet).
>
> I was thinking either we have a way of identifying codegen-only passes and
> revert back to the legacy PM in opt whenever we see one, or we go back to
> considering the originally intended approach of adding an equivalent
> `-passes=` RUN to all tests that should be also running under NPM.
>
> I'm not sure of a nice and clean solution to identify codegen-only
passes.
> We could go and update every instance of INITIALIZE_PASS to take another
> parameter indicating if it's codegen-only. Or we could just have a
central
> list somewhere where we check if the pass is in some hardcoded list or has
> some prefix (e.g. "x86-").
>
> The approach of adding equivalent `-passes=` RUN lines to all relevant
> tests seems daunting, but not exactly sure how daunting. Maybe it's
> possible to script something and see what fails? We'd still need some
way
> to identify codegen-only passes to make sure we don't miss anything,
and
> we'd need to distinguish between analyses and normal passes. Also, it
would
> slow down test execution since we'd run a lot more tests twice, but
maybe
> that's not such a big deal? Maybe it's good to have most tests
running
> against the legacy PM even when NPM is on by default?
>
> Thoughts?
>
> This is split off from
> http://lists.llvm.org/pipermail/llvm-dev/2020-July/143395.html.
>
>
>
> _______________________________________________
> LLVM Developers mailing listllvm-dev at
lists.llvm.orghttps://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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200722/8c28dba3/attachment.html>

On Thu, 23 Jul 2020 at 00:05, Chen, Yuanfang via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> > But a large portion of the remaining failures are because codegen-only
passes haven't been ported to NPM yet. That's fine for the optimization
pipeline NPM transition since it doesn't affect the optimization pipeline,
but it does present an issue with the approach of the -enable-new-pm flag (which
would by default become true alongside the NPM transition). Lots of tests are
testing codegen-specific passes via opt (e.g. `opt -amdgpu-lower-intrinsics`)
and they can't use NPM (yet).
>
> I think the ideal way is just to port these to NPM. The problem is if the
opt pipeline NPM switch is blocked on this, we’re forcing the targets to start
porting which I’m not sure if target owners want to do.
I can't speak for other targets but I'd love to get AMDGPU passes
converted to the NPM. Is there a howto somewhere?

Thanks,
Jay.

While I'm also excited about moving to the new pass manager, I do
think you may be overestimating how many users have switched when you
write that the vast majority of testing is now using the NPM.

My guess would instead be that the vast majority of projects using
LLVM are using default pass manager. I know Chrome uses the default. I
know that's how the upstream releases are built and tested. Defaults
tend to be popular. All our docs about writing passes and such seem to
assume the default pm.

I guess what I'm saying is I think the transition has to be more
careful than biting the bullet and throwing the switch today.

On Thu, Jul 23, 2020 at 12:15 AM Philip Reames via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> (I'm probably going to derail your thread, sorry about that.)
>
> I think at this point, we should just bite the bullet and make the switch
to NPM by default for Clang's optimization pipeline.  Today.
>
> Why?  Because many of our downstream consumers have already switched. 
Google has.  We (Azul) have.  I think I've heard the same for a couple other
major contributors.  Why does this matter?  Testing.  At the current moment, the
vast majority of testing the project gets is exercising NPM, not LPM.
>
> NPM is functionally complete for Clang optimization.  There might be a few
missing cases around the sanitizers, but last I heard those were on the edge of
being fixed.
>
> I think we should make the switch, and deal with any fall out as
regressions.  If we made the change immediately after a release branch, we'd
have several months to address any major issues before the next release.
>
> Philip
>
> On 7/22/20 2:39 PM, Arthur Eubanks via llvm-dev wrote:
>
> Hi all,
>
> I wanted to give a quick update on the status of NPM for the IR
optimization pipeline and ask some questions.
>
> In the past I believe there were thoughts that NPM was basically ready
because all of check-llvm and check-clang passed when
-DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=ON was specified. But that CMake flag did
not apply to opt and any tests running something like `opt -foo-pass -bar-pass`
(which is the vast majority of check-llvm tests) were still using the legacy PM.
The intended way to use NPM was to use the -passes flag, e.g. `opt
-passes='foo,bar'`.
>
> I've added a -enable-new-pm flag to opt to force running NPM passes
even when `opt -foo-pass` is used. This is because I didn't want to go
through every single test and figure out which ones should be using both
-foo-pass and -passes=foo. Switching on -enable-new-pm currently leads to ~1800
check-llvm failures. I've documented the failed tests count per directory in
https://bugs.llvm.org/show_bug.cgi?id=46651 (some have been fixed since that was
posted).
>
> This has led to real bugs in NPM being discovered and fixed (e.g. some
optnone issues).
>
> But a large portion of the remaining failures are because codegen-only
passes haven't been ported to NPM yet. That's fine for the optimization
pipeline NPM transition since it doesn't affect the optimization pipeline,
but it does present an issue with the approach of the -enable-new-pm flag (which
would by default become true alongside the NPM transition). Lots of tests are
testing codegen-specific passes via opt (e.g. `opt -amdgpu-lower-intrinsics`)
and they can't use NPM (yet).
>
> I was thinking either we have a way of identifying codegen-only passes and
revert back to the legacy PM in opt whenever we see one, or we go back to
considering the originally intended approach of adding an equivalent `-passes=`
RUN to all tests that should be also running under NPM.
>
> I'm not sure of a nice and clean solution to identify codegen-only
passes. We could go and update every instance of INITIALIZE_PASS to take another
parameter indicating if it's codegen-only. Or we could just have a central
list somewhere where we check if the pass is in some hardcoded list or has some
prefix (e.g. "x86-").
>
> The approach of adding equivalent `-passes=` RUN lines to all relevant
tests seems daunting, but not exactly sure how daunting. Maybe it's possible
to script something and see what fails? We'd still need some way to identify
codegen-only passes to make sure we don't miss anything, and we'd need
to distinguish between analyses and normal passes. Also, it would slow down test
execution since we'd run a lot more tests twice, but maybe that's not
such a big deal? Maybe it's good to have most tests running against the
legacy PM even when NPM is on by default?
>
> Thoughts?
>
> This is split off from
http://lists.llvm.org/pipermail/llvm-dev/2020-July/143395.html.
>
>
>
> _______________________________________________
> 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

On Wed, Jul 22, 2020 at 4:05 PM Chen, Yuanfang <Yuanfang.Chen at sony.com>
wrote:
>
>
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of
*Arthur
> Eubanks via llvm-dev
> *Sent:* Wednesday, July 22, 2020 2:39 PM
> *To:* llvm-dev <llvm-dev at lists.llvm.org>
> *Subject:* [llvm-dev] New pass manager for optimization pipeline status
> and questions
>
>
>
> Hi all,
>
>
>
> I wanted to give a quick update on the status of NPM for the IR
> optimization pipeline and ask some questions.
>
>
>
> In the past I believe there were thoughts that NPM was basically ready
> because all of check-llvm and check-clang passed when
> -DENABLE_EXPERIMENTAL_NEW_PASS_MANAGER=ON was specified. But that CMake
> flag did not apply to opt and any tests running something like `opt
> -foo-pass -bar-pass` (which is the vast majority of check-llvm tests) were
> still using the legacy PM. The intended way to use NPM was to use the
> -passes flag, e.g. `opt -passes='foo,bar'`.
>
>
>
> I've added a -enable-new-pm flag to opt to force running NPM passes
even
> when `opt -foo-pass` is used. This is because I didn't want to go
through
> every single test and figure out which ones should be using both -foo-pass
> and -passes=foo. Switching on -enable-new-pm currently leads to ~1800
> check-llvm failures. I've documented the failed tests count per
directory
> in https://bugs.llvm.org/show_bug.cgi?id=46651 (some have been fixed
> since that was posted).
>
>
>
> This has led to real bugs in NPM being discovered and fixed (e.g. some
> optnone issues).
>
>
>
> But a large portion of the remaining failures are because codegen-only
> passes haven't been ported to NPM yet. That's fine for the
optimization
> pipeline NPM transition since it doesn't affect the optimization
pipeline,
> but it does present an issue with the approach of the -enable-new-pm flag
> (which would by default become true alongside the NPM transition). Lots of
> tests are testing codegen-specific passes via opt (e.g. `opt
> -amdgpu-lower-intrinsics`) and they can't use NPM (yet).
>
>
>
> I think the ideal way is just to port these to NPM. The problem is if the
> opt pipeline NPM switch is blocked on this, we’re forcing the targets to
> start porting which I’m not sure if target owners want to do.
>
> On the other end, we’re (almost) actually ready to make these target IR
> passes use NPM for testing purpose with `opt` tool. Except there needs a
> way to expose these passes through llvm/lib/Target, llvm/lib/CodeGen rather
> than llvm/lib/Passes to `opt`. As part of the codegen using NPM work, this
> is almost done.
>
Grepping for INITIALIZE_PASS in llvm/lib/Target, there are 220 files with
that. That means there are ~200 target specific passes. There's no way
we'll be able to port all of those in a reasonable amount of time.
Plus it's not a blocker if we can detect passes are target specific and
simply revert to the legacy PM in opt. Then as codegen passes are ported to
NPM we can start running those on NPM instead reverting back to the legacy
PM. The exact mechanism for this TBD, although probably something similar
to below.
>
>
> I was thinking either we have a way of identifying codegen-only passes and
> revert back to the legacy PM in opt whenever we see one, or we go back to
> considering the originally intended approach of adding an equivalent
> `-passes=` RUN to all tests that should be also running under NPM.
>
>
>
> I would prefer the former since it sounds less pervasive.
>
>
>
> I'm not sure of a nice and clean solution to identify codegen-only
passes.
> We could go and update every instance of INITIALIZE_PASS to take another
> parameter indicating if it's codegen-only. Or we could just have a
central
> list somewhere where we check if the pass is in some hardcoded list or has
> some prefix (e.g. "x86-").
>
>
>
> The latter seems in line with the progress has been made on codegen using
> NPM work where each target would maintain their own pass registry like
> PassRegister.def. For x86, it is (tentatively) called X86PassRegistry.def.
(
> https://reviews.llvm.org/D83613). If It is useful for the opt pipeline
> NPM switch, we could find a way to factor it out.
>
If we can add an equivalent of something like PassBuilder::isAAPassName()
to https://reviews.llvm.org/D83613
(X86CodeGenPassBuilder::isX86CodeGenPassName()?) that
would definitely work.
>
>
> The approach of adding equivalent `-passes=` RUN lines to all relevant
> tests seems daunting, but not exactly sure how daunting. Maybe it's
> possible to script something and see what fails? We'd still need some
way
> to identify codegen-only passes to make sure we don't miss anything,
and
> we'd need to distinguish between analyses and normal passes. Also, it
would
> slow down test execution since we'd run a lot more tests twice, but
maybe
> that's not such a big deal? Maybe it's good to have most tests
running
> against the legacy PM even when NPM is on by default?
>
>
>
> Thoughts?
>
>
>
> This is split off from
> http://lists.llvm.org/pipermail/llvm-dev/2020-July/143395.html.
>
>
>
>
 I can't speak for other targets but I'd love to get AMDGPU
passes
> converted to the NPM. Is there a howto somewhere?
>
I don't think so, but it's usually fairly straightforward, looking at
other
passes that exist in both PMs is usually good. I should rewrite
https://llvm.org/docs/WritingAnLLVMPass.html to reference NPM.
But specifically for codegen passes we're currently blocked on ychen's
work
for codegen passes infra in NPM:
http://lists.llvm.org/pipermail/llvm-dev/2020-July/143309.html.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200723/261fc44e/attachment.html>