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

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/1b68de9b/attachment-0001.html>

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>