<div dir="ltr">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.<div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">~Craig</div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 16, 2020 at 5:01 PM Chen, Yuanfang via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br>
<br>
________________________________________<br>
From: Nicolai Hähnle <<a href="mailto:nhaehnle@gmail.com" target="_blank">nhaehnle@gmail.com</a>><br>
Sent: Thursday, July 16, 2020 12:25 AM<br>
To: Chen, Yuanfang<br>
Cc: Matt Arsenault; <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
Subject: Re: [llvm-dev] [RFC] Introducing classes for the codegen driven by new pass manager<br>
<br>
On Wed, Jul 15, 2020 at 6:39 PM Chen, Yuanfang via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> Indeed, but there is a distinction about their position in the pipeline. We run opt & codegen pipeline separately,<br>
<br>
Why, though? Is there a reason why this inherently makes sense, or is<br>
it just a historical accident? At least to me it seems that it would<br>
make more sense to run all passes within a single pipeline.<br>
<br>
Cheers,<br>
Nicolai<br>
<br>
<br>
<br>
><br>
> 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.<br>
><br>
> ________________________________________<br>
> From: Matt Arsenault <<a href="mailto:whatmannerofburgeristhis@gmail.com" target="_blank">whatmannerofburgeristhis@gmail.com</a>> on behalf of Matt Arsenault <<a href="mailto:arsenm2@gmail.com" target="_blank">arsenm2@gmail.com</a>><br>
> Sent: Wednesday, July 15, 2020 9:31 AM<br>
> To: Chen, Yuanfang<br>
> Cc: Robinson, Paul; <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> Subject: Re: [llvm-dev] [RFC] Introducing classes for the codegen driven by new pass manager<br>
><br>
><br>
><br>
> > On Jul 15, 2020, at 12:28, Chen, Yuanfang <<a href="mailto:Yuanfang.Chen@sony.com" target="_blank">Yuanfang.Chen@sony.com</a>> wrote:<br>
> ><br>
> > 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.<br>
> ><br>
><br>
><br>
> 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.<br>
><br>
> -Matt<br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br>
<br>
<br>
--<br>
Lerne, wie die Welt wirklich ist,<br>
aber vergiss niemals, wie sie sein sollte.<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>