llvm dev - Apr 2021 - Legacy PM deprecation for optimization pipeline timeline

Hello everyone

I wouldn't mind looking into hooking the new PM infrastructure into the
LLVM C API. However, I would like to know a little more about the task.
I've had a look at the new PM infrastructure, and from taking a quick
glance at the available APIs and how it's used in the tests I assume
we'd
look to do something similar to the existing legacy PM hooks.

Things are a bit different as far as I've understood because we have
Module, CGSCC, Function, and Loop passes, each of which may be adapted into
"higher" kinds, eg FunctionPM -> ModulePM, all of which differs a
bit from
the legacy PM. From what I've gathered, we'll need to set up the PMs
themselves as you mentioned and we'll have to hook a set (all?) of the new
PM passes into this. Would it be possible to get a more comprehensive list
of what needs to be done?

I'm pretty new around here so I'll probably require some guidance
further
down the line.

Best regards
Mats

On Thu, Apr 22, 2021 at 11:17 PM Arthur Eubanks via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Splitting this off from the other thread.
>
> 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.
>
> 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.
>
> 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`.
> _______________________________________________
> 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/20210426/d3a244b9/attachment.html>

On Mon, Apr 26, 2021 at 1:48 PM Mats Larsen <me at supergrecko.com> wrote:
> Hello everyone
>
> I wouldn't mind looking into hooking the new PM infrastructure into the
> LLVM C API. However, I would like to know a little more about the task.
> I've had a look at the new PM infrastructure, and from taking a quick
> glance at the available APIs and how it's used in the tests I assume
we'd
> look to do something similar to the existing legacy PM hooks.
>
> Things are a bit different as far as I've understood because we have
> Module, CGSCC, Function, and Loop passes, each of which may be adapted into
> "higher" kinds, eg FunctionPM -> ModulePM, all of which
differs a bit from
> the legacy PM. From what I've gathered, we'll need to set up the
PMs
> themselves as you mentioned and we'll have to hook a set (all?) of the
new
> PM passes into this. Would it be possible to get a more comprehensive list
> of what needs to be done?
>
> I'm pretty new around here so I'll probably require some guidance
further
> down the line.
>>
>> <https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>>
> Awesome, I'm happy to do reviews and answer any further questions.
I'm imagining a new PassBuilder.h in llvm/include/llvm-c where
PassManagerBuilder.h was.
Initially I was thinking we'd need wrappers around the various types of
pass managers as you've mentioned, as well as the adaptors
(e.g. createModuleToFunctionPassAdaptor()). And each of the LLVMAdd*Pass()
would need a corresponding new PM alternative that adds the pass to the
proper pass manager type.

But now that I think about it some more, we might be able to bypass all of
that and instead use the new PM's pass pipeline text parsing (the same
thing that `opt -passes=foo` uses). This seems exactly the sort of thing it
would be useful for. We'll bypass the need to create wrappers for the
different types of pass managers since we just get back a ModulePassManager
from the PassBuilder.
The code in NewPMDriver.cpp should be a good starting place to figure out
what's necessary to create a PassBuilder, then how to get a
ModulePassManager from it and run it on some IR.
I imagine first you'll need some way to setup the options to pass to the
PassBuilder, so the C wrapper would probably own various things like the
various
*AnalysisManagers, PassInstrumentationCallbacks, StandardInstrumentations,
and PipelineTuningOptions. Then the user can ask for some pipeline via a
string, whether that's an individual pass like "instcombine" or a
full
pipeline like "default<O2>", and you create a PassBuilder from
the
options, then tell it to create the ModulePassManager via
PassBuilder::parsePassPipeline().
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20210427/d7c94154/attachment.html>