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

[Jay Foad via llvm-dev]

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