[llvm-dev] Legacy PM deprecation for optimization pipeline timeline

[Arthur Eubanks via llvm-dev]

Yes, if some backend adds an IR pass then we'll still need to support it
for the legacy PM.

On Fri, Apr 30, 2021 at 6:45 AM Jay Foad <jay.foad at gmail.com> wrote:

> Does the deprecation mean that individual IR passes might stop
> supporting the legacy PM? If so I have a slight concern: at the moment
> a target can pull arbitrary IR passes into the codegen pipeline. For
> example, AMDGPU's addPreISel() hook does this:
>   addPass(createSinkingPass());
> I guess most people would consider Sinking to be an optimization pass
> that would only be used in the optimization pipeline, but that ain't
> necessarily so. In fact I'm not sure if there is any reliable
> definition of which IR passes are really codegen passes, is there?
>
> Jay.
>
> On Thu, 22 Apr 2021 at 22:18, 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/20210503/7763c490/attachment.html>