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

Craig Topper via llvm-dev llvm-dev at lists.llvm.org
Tue Jul 21 11:53:39 PDT 2020


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>


More information about the llvm-dev mailing list