<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 26, 2021 at 2:33 AM Björn Pettersson A <<a href="mailto:bjorn.a.pettersson@ericsson.com">bjorn.a.pettersson@ericsson.com</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">
<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="gmail-m_-7148938609752020630WordSection1">
<p class="MsoNormal">For a downstream maintainer that is doing regular merges/rebases toward main (kind of on a daily basis) it is really nice to have a timeline for this.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">A bit unclear to me what your proposal would mean though. Is it that after the LLVM 13 branch out we could expect that the support for Legacy PM will start to “disappear” in opt on the main branch (i.e. when the version on main branch is
stepped to 14, which will happen before the LLVM 13 release)?<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">When it comes to “disappear” I figure that:<u></u><u></u></p>
<ul style="margin-top:0cm" type="disc">
<li class="gmail-m_-7148938609752020630MsoListParagraph" style="margin-left:0cm">At some point lit tests, today running new-pm by default, will be converted to use -passes.<br>
(This should not be a big problem for myself at least. We’ve actually started to build with the default setting for ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER, to make sure we use the default for “upstream” tests/targets, but we are forcing the legacy PM by an override
in opt.cpp for our downstream target.)<u></u><u></u></li><li class="gmail-m_-7148938609752020630MsoListParagraph" style="margin-left:0cm">At some point lit tests will stop testing legacy PM completely (no more using -enable-new-pm=0).<br>
(This is a point in the timeline that could be interesting for us, as we probably want to have switched over into using new PM downstream before quality of legacy PM this.)<u></u><u></u></li><li class="gmail-m_-7148938609752020630MsoListParagraph" style="margin-left:0cm">At some point passes that are specific to Legacy PM will be removed.<br>
(If I need then downstream I’d probably need to maintain them myself just like any downstream pass, so shouldn’t be a big problem. However, we probably want to aim for switching to use new PM downstream before this happens.)<u></u><u></u></li><li class="gmail-m_-7148938609752020630MsoListParagraph" style="margin-left:0cm">At some point in time flags/options like -enable-new-pm and ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER will be dropped, along with support in opt.cpp to use the legacy PM.<br>
(Here I think that we definitely want to have switched to use new PM downstream, because maintaining that OOT is probably more costly.)<u></u><u></u></li></ul>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Is the plan that all those things will start to happen more or less at once?</p></div></div></blockquote><div>That mostly sounds right to me.</div><div>We'd still have to have support in opt for the legacy PM to run IR passes that are part of the codegen pipeline. But we could still remove the -enable-new-pm flag after moving tests for passes in the optimization pipeline to use -passes.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_-7148938609752020630WordSection1"><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Regards,<u></u><u></u></p>
<p class="MsoNormal">Björn<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border-top:none;border-right:none;border-bottom:none;border-left:1.5pt solid blue;padding:0cm 0cm 0cm 4pt">
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0cm 0cm">
<p class="MsoNormal"><b>From:</b> llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>> <b>On Behalf Of
</b>Arthur Eubanks via llvm-dev<br>
<b>Sent:</b> den 23 april 2021 00:44<br>
<b>To:</b> Shoaib Meenai <<a href="mailto:smeenai@fb.com" target="_blank">smeenai@fb.com</a>><br>
<b>Cc:</b> llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Subject:</b> Re: [llvm-dev] Legacy PM deprecation for optimization pipeline timeline<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">Ah you're right. And now I remember that it was intentionally submitted after the branch.<u></u><u></u></p>
<div>
<p class="MsoNormal">So s/12/13/<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Thu, Apr 22, 2021 at 3:22 PM Shoaib Meenai <<a href="mailto:smeenai@fb.com" target="_blank">smeenai@fb.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal">I don’t think the new PM switch is part of LLVM 12. The change to make it the default landed on February 3rd, which was after the branch cut. If you examine llvm/CMakeLists.txt
on the release/12.x branch, you’ll also see that ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER still defaults to FALSE.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(181,196,223);padding:3pt 0cm 0cm">
<p class="MsoNormal" style="margin-left:36pt">
<b><span style="font-size:12pt;color:black">From: </span></b><span style="font-size:12pt;color:black">llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.org</a>> on behalf of Arthur Eubanks via llvm-dev
<<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Reply-To: </b>Arthur Eubanks <<a href="mailto:aeubanks@google.com" target="_blank">aeubanks@google.com</a>><br>
<b>Date: </b>Thursday, April 22, 2021 at 2:18 PM<br>
<b>To: </b>llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Subject: </b>[llvm-dev] Legacy PM deprecation for optimization pipeline timeline</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36pt">
<u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-left:36pt">
Splitting this off from the other thread.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36pt">
<u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-left:36pt">
We should have a deprecation timeline that revolves around the major releases. I'd say we announce the legacy PM for the optimization pipeline to be deprecated the major release after the new PM has been the default. Looks like the new PM switch made it into
LLVM 12.<u></u><u></u></p>
<div>
<p class="MsoNormal" style="margin-left:36pt">
<br>
The major blocker right now is that the C API doesn't have hooks into the new PM infrastructure. llvm/include/llvm-c/Transforms/PassManagerBuilder.h should be fairly straightforward to port to the new PM, but the API to add individual passes (e.g. llvm/include/llvm-c/Transforms/Scalar.h)
needs to distinguish between the different types of passes, e.g. module vs function pass. The new PM has explicit pass nesting, so we'll need to make sure that we add a function pass to a function pass manager. Or we could simplify things and force each pass
added via the C API to run in isolation (e.g. two adjacent function passes would run completely separately rather than being interleaved function-by-function), which doesn't match how pipelines are constructed everywhere else, but it's already an adhoc API.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36pt">
<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:36pt">
At some point after the deprecation announcement we should start cleaning up tests for passes in the optimization pipeline to use `opt -passes=foo` rather than `opt -foo`.<u></u><u></u></p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote></div></div>