Arthur Eubanks via llvm-dev
2021-Apr-22 21:17 UTC
[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/39e48415/attachment.html>
Shoaib Meenai via llvm-dev
2021-Apr-22 22:22 UTC
[llvm-dev] 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>
Mats Larsen via llvm-dev
2021-Apr-26 20:48 UTC
[llvm-dev] 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>
Jay Foad via llvm-dev
2021-Apr-30 13:44 UTC
[llvm-dev] Legacy PM deprecation for optimization pipeline timeline
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
Arthur Eubanks via llvm-dev
2021-May-03 16:45 UTC
[llvm-dev] Legacy PM deprecation for optimization pipeline timeline
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>