[llvm-dev] [RFC] Introducing classes for the codegen driven by new pass manager
Nicolai Hähnle via llvm-dev
llvm-dev at lists.llvm.org
Thu Jul 16 00:25:04 PDT 2020
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.
More information about the llvm-dev
mailing list