llvm dev - Jul 2020 - [RFC] Introducing classes for the codegen driven by new pass manager

One thing I want to mention. I believe in the current legacy pass manager
implementation only one MachineFunction ever exists at a time. It is
deleted before the next MachineFunction is created. This is very
important for memory usage. I think the MachineOutliner being in the
pipeline may create an exception to this. I think the initial version of
retpoline used a ModulePass and that had to be changed to avoid excessive
memory usage.

~Craig


On Thu, Jul 16, 2020 at 5:01 PM Chen, Yuanfang via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> TBH, I don't know the history of this choice. Although it makes sense
from
> the debugging/testing point of view. We have IR / MIR difference so it
> makes sense to have their own pipeline (yeah, MIR pipeline is prefixed with
> an IR pipeline to prepare the module, but that is just implementation
> detail). And then we have opt/llc to test the pipeline separately.
> Combining them in a single pipeline is possible, but AFAIK it does not have
> many benefits in practice.
>
> ________________________________________
> From: Nicolai Hähnle <nhaehnle at gmail.com>
> Sent: Thursday, July 16, 2020 12:25 AM
> To: Chen, Yuanfang
> Cc: Matt Arsenault; llvm-dev at lists.llvm.org
> Subject: Re: [llvm-dev] [RFC] Introducing classes for the codegen driven
> by new pass manager
>
> On Wed, Jul 15, 2020 at 6:39 PM Chen, Yuanfang via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > Indeed, but there is a distinction about their position in the
pipeline.
> We run opt & codegen pipeline separately,
>
> Why, though? Is there a reason why this inherently makes sense, or is
> it just a historical accident? At least to me it seems that it would
> make more sense to run all passes within a single pipeline.
>
> Cheers,
> Nicolai
>
>
>
> >
> > Do you run “codegen” IR passes with regular IR passes? If so, do you
> mind sharing the use cases? I might have missed this use case.
> >
> > ________________________________________
> > From: Matt Arsenault <whatmannerofburgeristhis at gmail.com> on
behalf of
> Matt Arsenault <arsenm2 at gmail.com>
> > Sent: Wednesday, July 15, 2020 9:31 AM
> > To: Chen, Yuanfang
> > Cc: Robinson, Paul; llvm-dev at lists.llvm.org
> > Subject: Re: [llvm-dev] [RFC] Introducing classes for the codegen
driven
> by new pass manager
> >
> >
> >
> > > On Jul 15, 2020, at 12:28, Chen, Yuanfang <Yuanfang.Chen at
sony.com>
> wrote:
> > >
> > > In codegen with NPM, I've made all codegen passes (IR or MIR
pass) to
> be only driven by `llc`. Both due to the way NPM registering pass
> (on-demand&dynamic instead of static initialization in Legacy PM), and
> reduce the confusion about which tool (`llc` or `opt`) to test codegen IR
> passes.
> > >
> >
> >
> > I think there’s no real distinction between “codegen” IR passes and
> noncodegen IR passes. I routinely run “codegen only” passes with opt in
> conjunction with other passes when experimenting. I think losing the
> ability to run any IR pass with opt would be a functionality regression.
> >
> > -Matt
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> --
> Lerne, wie die Welt wirklich ist,
> aber vergiss niemals, wie sie sein sollte.
> _______________________________________________
> 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/20200721/562ee4f6/attachment.html>

> On Jul 21, 2020, at 14:53, Craig Topper <craig.topper at gmail.com>
wrote:
> 
> One thing I want to mention. I believe in the current legacy pass manager
implementation only one MachineFunction ever exists at a time. It is deleted
before the next MachineFunction is created. This is very important for memory
usage. I think the MachineOutliner being in the pipeline may create an exception
to this. I think the initial version of retpoline used a ModulePass and that had
to be changed to avoid excessive memory usage.
> 
> ~Craig
An addition to this is analyses between different MachineFunctions still matter.
AMDGPU forces SCC order and has an analysis to track function information after
it’s been codegened. This is needed to track the cumulative register usage of
kernels

-Matt

Thanks, Craig. I will address this in the patch. It is unfortunate that
MachineOutliner needs to keep all MachineFunction in memory and it is located
just before emitting. So once it is used, all MachineFunctions are in memory
almost for the whole codegen process. AFAIK, there is no good way to address
this. Hopefully, we don't have many exceptions like this.

________________________________________
From: Craig Topper <craig.topper at gmail.com>
Sent: Tuesday, July 21, 2020 11:53 AM
To: Chen, Yuanfang
Cc: Nicolai Hähnle; llvm-dev at lists.llvm.org; Matt Arsenault
Subject: Re: [llvm-dev] [RFC] Introducing classes for the codegen driven by new
pass manager

One thing I want to mention. I believe in the current legacy pass manager
implementation only one MachineFunction ever exists at a time. It is deleted
before the next MachineFunction is created. This is very important for memory
usage. I think the MachineOutliner being in the pipeline may create an exception
to this. I think the initial version of retpoline used a ModulePass and that had
to be changed to avoid excessive memory usage.

~Craig


On Thu, Jul 16, 2020 at 5:01 PM Chen, Yuanfang via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
TBH, I don't know the history of this choice. Although it makes sense from
the debugging/testing point of view. We have IR / MIR difference so it makes
sense to have their own pipeline (yeah, MIR pipeline is prefixed with an IR
pipeline to prepare the module, but that is just implementation detail). And
then we have opt/llc to test the pipeline separately. Combining them in a single
pipeline is possible, but AFAIK it does not have many benefits in practice.

________________________________________
From: Nicolai Hähnle <nhaehnle at gmail.com<mailto:nhaehnle at
gmail.com>>
Sent: Thursday, July 16, 2020 12:25 AM
To: Chen, Yuanfang
Cc: Matt Arsenault; llvm-dev at lists.llvm.org<mailto:llvm-dev at
lists.llvm.org>
Subject: Re: [llvm-dev] [RFC] Introducing classes for the codegen driven by new
pass manager

On Wed, Jul 15, 2020 at 6:39 PM Chen, Yuanfang via llvm-dev
<llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>>
wrote:
> Indeed, but there is a distinction about their position in the pipeline. We
run opt & codegen pipeline separately,
Why, though? Is there a reason why this inherently makes sense, or is
it just a historical accident? At least to me it seems that it would
make more sense to run all passes within a single pipeline.

Cheers,
Nicolai


>
> Do you run “codegen” IR passes with regular IR passes? If so, do you mind
sharing the use cases? I might have missed this use case.
>
> ________________________________________
> From: Matt Arsenault <whatmannerofburgeristhis at
gmail.com<mailto:whatmannerofburgeristhis at gmail.com>> on behalf of
Matt Arsenault <arsenm2 at gmail.com<mailto:arsenm2 at gmail.com>>
> Sent: Wednesday, July 15, 2020 9:31 AM
> To: Chen, Yuanfang
> Cc: Robinson, Paul; llvm-dev at lists.llvm.org<mailto:llvm-dev at
lists.llvm.org>
> Subject: Re: [llvm-dev] [RFC] Introducing classes for the codegen driven by
new pass manager
>
>
>
> > On Jul 15, 2020, at 12:28, Chen, Yuanfang <Yuanfang.Chen at
sony.com<mailto:Yuanfang.Chen at sony.com>> wrote:
> >
> > In codegen with NPM, I've made all codegen passes (IR or MIR pass)
to be only driven by `llc`. Both due to the way NPM registering pass
(on-demand&dynamic instead of static initialization in Legacy PM), and
reduce the confusion about which tool (`llc` or `opt`) to test codegen IR
passes.
> >
>
>
> I think there’s no real distinction between “codegen” IR passes and
noncodegen IR passes. I routinely run “codegen only” passes with opt in
conjunction with other passes when experimenting. I think losing the ability to
run any IR pass with opt would be a functionality regression.
>
> -Matt
> _______________________________________________
> 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


--
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.
_______________________________________________
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

Hi Matt, which analysis is this?
________________________________________
From: Matt Arsenault <whatmannerofburgeristhis at gmail.com> on behalf of
Matt Arsenault <arsenm2 at gmail.com>
Sent: Tuesday, July 21, 2020 12:02 PM
To: Craig Topper
Cc: Chen, Yuanfang; Nicolai Hähnle; llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] [RFC] Introducing classes for the codegen driven by new
pass manager


> On Jul 21, 2020, at 14:53, Craig Topper <craig.topper at gmail.com>
wrote:
>
> One thing I want to mention. I believe in the current legacy pass manager
implementation only one MachineFunction ever exists at a time. It is deleted
before the next MachineFunction is created. This is very important for memory
usage. I think the MachineOutliner being in the pipeline may create an exception
to this. I think the initial version of retpoline used a ModulePass and that had
to be changed to avoid excessive memory usage.
>
> ~Craig
An addition to this is analyses between different MachineFunctions still matter.
AMDGPU forces SCC order and has an analysis to track function information after
it’s been codegened. This is needed to track the cumulative register usage of
kernels

-Matt