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

[Arthur Eubanks via llvm-dev]

Ah you're right. And now I remember that it was intentionally submitted
after the branch.
So s/12/13/

On Thu, Apr 22, 2021 at 3:22 PM Shoaib Meenai <smeenai at fb.com> wrote:

> 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.
>
>
>
> *From: *llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Arthur
> Eubanks via llvm-dev <llvm-dev at lists.llvm.org>
> *Reply-To: *Arthur Eubanks <aeubanks at google.com>
> *Date: *Thursday, April 22, 2021 at 2:18 PM
> *To: *llvm-dev <llvm-dev at lists.llvm.org>
> *Subject: *[llvm-dev] Legacy PM deprecation for optimization pipeline
> timeline
>
>
>
> 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`.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210422/ef5a11bb/attachment.html>