Hal Finkel via llvm-dev
2017-Oct-25 17:19 UTC
[llvm-dev] RFC: Switching to the new pass manager by default
On 10/25/2017 12:16 PM, Xinliang David Li via llvm-dev wrote:> > > On Tue, Oct 17, 2017 at 11:50 PM, Chandler Carruth via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Greetings everyone! > > The new pass manager is getting extremely close to the point where > I'm not aware of any significant outstanding work needed, and I'd > like to see what else would be needed to enable it by default. > Here are the current functionality I'm aware of outstanding: > > 1) Does not do non-trivial loop unswitching. Majority of this is > in https://reviews.llvm.org/D34200 > <https://reviews.llvm.org/D34200> but will need one or two small > follow-ups. > > 2) Currently, sanitizers don't work correctly with it. Thanks to > the work of others, the missing infrastructure has been added and > I'll send a patch to wire this up this week. > > 3) Missing support for 'optnone'. I've been working on this, but > the existing testing wasn't as thorough as I wanted, so it is > going slowly. I've got about 1/4 of this implemented and should > have patches this week or next. > > 4) Missing opt-bisect (or similar) facility. This looks pretty > trivial to add, but I've not even started. If anyone is interested > in it, go for it. We might even be able to do something simpler > using the generic debug counters and get equivalent functionality. > > ... that's it? > > > > Missing support of 'print-after-all' or 'print-after-passX' is > another major usability loss. > > Regarding the default switch, maybe do it in two steps: > > 1) Switch the default for PGO build first > 2) Switch the default for all modes.Why? -Hal> > David > > > > Optimization quality / run-time performance: > - We've been using it at Google extensively and are very happy > with the optimization quality. Benchmarks look *very* good here. > - More data from other users would be important. > - You can try it out with `-fexperimental-new-pass-manager` to Clang > > Compile-time performance: > - Sometimes *much* better due to cached analyses. > - Sometimes worse, typically due to more / different inlining in > turn running main pipeline (GVN + InstCombine) more times or over > more code. > - Overall somewhat a wash, but the increased compile times > typically due to the optimizer "trying" harder, so not too > concerning on our end. > - Again, more feedback from other users good: > `-fexperimental-new-pass-manager` to Clang > > Once the four missing things land, I'll also happily work on > collecting some of the basics on the test-suite and CTMark. But I > suspect more "in the wild" data would really be useful here given > the significance of the change. > > Thoughts? What else (beyond the four items above and feedback on > run-time and compile-time) would folks like to see? > > Once this happens, I'll also be preparing some batch, mechanical > updates to the test suite to primarily use the new pass manager. > Also there is lots of documentation updates that will be needed here. > > -Chandler > > PS: I'll be sending a note to cfe-dev as a "heads up" about this > discussion as in some ways, the default flip is mostly a Clang > default flip. But hopefully our doc updates will trigger this > being "perceived" as the default for other frontends, and I'll try > to reach out to other major frontends as well (Swift and Rust are > on my radar, and I've already started talking with Philip Reames > about their Falcon JIT). > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171025/51b96431/attachment-0001.html>
Xinliang David Li via llvm-dev
2017-Oct-25 17:21 UTC
[llvm-dev] RFC: Switching to the new pass manager by default
On Wed, Oct 25, 2017 at 10:19 AM, Hal Finkel <hfinkel at anl.gov> wrote:> > On 10/25/2017 12:16 PM, Xinliang David Li via llvm-dev wrote: > > > > On Tue, Oct 17, 2017 at 11:50 PM, Chandler Carruth via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Greetings everyone! >> >> The new pass manager is getting extremely close to the point where I'm >> not aware of any significant outstanding work needed, and I'd like to see >> what else would be needed to enable it by default. Here are the current >> functionality I'm aware of outstanding: >> >> 1) Does not do non-trivial loop unswitching. Majority of this is in >> https://reviews.llvm.org/D34200 but will need one or two small >> follow-ups. >> >> 2) Currently, sanitizers don't work correctly with it. Thanks to the work >> of others, the missing infrastructure has been added and I'll send a patch >> to wire this up this week. >> >> 3) Missing support for 'optnone'. I've been working on this, but the >> existing testing wasn't as thorough as I wanted, so it is going slowly. >> I've got about 1/4 of this implemented and should have patches this week or >> next. >> >> 4) Missing opt-bisect (or similar) facility. This looks pretty trivial to >> add, but I've not even started. If anyone is interested in it, go for it. >> We might even be able to do something simpler using the generic debug >> counters and get equivalent functionality. >> >> ... that's it? >> > > > Missing support of 'print-after-all' or 'print-after-passX' is another > major usability loss. > > Regarding the default switch, maybe do it in two steps: > > 1) Switch the default for PGO build first > 2) Switch the default for all modes. > > > Why? > >1) PGO users benefit from the PM change the most 2) I suppose incremental changes are always better and causes fewer churns? David> -Hal > > > David > > > > >> >> Optimization quality / run-time performance: >> - We've been using it at Google extensively and are very happy with the >> optimization quality. Benchmarks look *very* good here. >> - More data from other users would be important. >> - You can try it out with `-fexperimental-new-pass-manager` to Clang >> >> Compile-time performance: >> - Sometimes *much* better due to cached analyses. >> - Sometimes worse, typically due to more / different inlining in turn >> running main pipeline (GVN + InstCombine) more times or over more code. >> - Overall somewhat a wash, but the increased compile times typically due >> to the optimizer "trying" harder, so not too concerning on our end. >> - Again, more feedback from other users good: >> `-fexperimental-new-pass-manager` to Clang >> >> Once the four missing things land, I'll also happily work on collecting >> some of the basics on the test-suite and CTMark. But I suspect more "in the >> wild" data would really be useful here given the significance of the change. >> >> Thoughts? What else (beyond the four items above and feedback on run-time >> and compile-time) would folks like to see? >> >> Once this happens, I'll also be preparing some batch, mechanical updates >> to the test suite to primarily use the new pass manager. Also there is lots >> of documentation updates that will be needed here. >> >> -Chandler >> >> PS: I'll be sending a note to cfe-dev as a "heads up" about this >> discussion as in some ways, the default flip is mostly a Clang default >> flip. But hopefully our doc updates will trigger this being "perceived" as >> the default for other frontends, and I'll try to reach out to other major >> frontends as well (Swift and Rust are on my radar, and I've already started >> talking with Philip Reames about their Falcon JIT). >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> > > > _______________________________________________ > LLVM Developers mailing listllvm-dev at lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > -- > Hal Finkel > Lead, Compiler Technology and Programming Languages > Leadership Computing Facility > Argonne National Laboratory > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171025/9d18c349/attachment.html>
Hal Finkel via llvm-dev
2017-Oct-25 17:42 UTC
[llvm-dev] RFC: Switching to the new pass manager by default
On 10/25/2017 12:21 PM, Xinliang David Li wrote:> > > On Wed, Oct 25, 2017 at 10:19 AM, Hal Finkel <hfinkel at anl.gov > <mailto:hfinkel at anl.gov>> wrote: > > > On 10/25/2017 12:16 PM, Xinliang David Li via llvm-dev wrote: >> >> >> On Tue, Oct 17, 2017 at 11:50 PM, Chandler Carruth via llvm-dev >> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> Greetings everyone! >> >> The new pass manager is getting extremely close to the point >> where I'm not aware of any significant outstanding work >> needed, and I'd like to see what else would be needed to >> enable it by default. Here are the current functionality I'm >> aware of outstanding: >> >> 1) Does not do non-trivial loop unswitching. Majority of this >> is in https://reviews.llvm.org/D34200 >> <https://reviews.llvm.org/D34200> but will need one or two >> small follow-ups. >> >> 2) Currently, sanitizers don't work correctly with it. Thanks >> to the work of others, the missing infrastructure has been >> added and I'll send a patch to wire this up this week. >> >> 3) Missing support for 'optnone'. I've been working on this, >> but the existing testing wasn't as thorough as I wanted, so >> it is going slowly. I've got about 1/4 of this implemented >> and should have patches this week or next. >> >> 4) Missing opt-bisect (or similar) facility. This looks >> pretty trivial to add, but I've not even started. If anyone >> is interested in it, go for it. We might even be able to do >> something simpler using the generic debug counters and get >> equivalent functionality. >> >> ... that's it? >> >> >> >> Missing support of 'print-after-all' or 'print-after-passX' is >> another major usability loss. >> >> Regarding the default switch, maybe do it in two steps: >> >> 1) Switch the default for PGO build first >> 2) Switch the default for all modes. > > Why? > > > 1) PGO users benefit from the PM change the most > 2) I suppose incremental changes are always better and causes fewer > churns?I'm somewhat nervous about having the PGO builds differ so much from the non-PGO builds. My thought is that: (Significant) regressions in execution performance or compile time need to be fixed regardless. Maybe there's some flexibility on code-size regressions (e.g., such that we could delay the transition for -Oz if necessary)? -Hal> > David > > -Hal > >> >> David >> >> >> >> Optimization quality / run-time performance: >> - We've been using it at Google extensively and are very >> happy with the optimization quality. Benchmarks look *very* >> good here. >> - More data from other users would be important. >> - You can try it out with `-fexperimental-new-pass-manager` >> to Clang >> >> Compile-time performance: >> - Sometimes *much* better due to cached analyses. >> - Sometimes worse, typically due to more / different inlining >> in turn running main pipeline (GVN + InstCombine) more times >> or over more code. >> - Overall somewhat a wash, but the increased compile times >> typically due to the optimizer "trying" harder, so not too >> concerning on our end. >> - Again, more feedback from other users good: >> `-fexperimental-new-pass-manager` to Clang >> >> Once the four missing things land, I'll also happily work on >> collecting some of the basics on the test-suite and CTMark. >> But I suspect more "in the wild" data would really be useful >> here given the significance of the change. >> >> Thoughts? What else (beyond the four items above and feedback >> on run-time and compile-time) would folks like to see? >> >> Once this happens, I'll also be preparing some batch, >> mechanical updates to the test suite to primarily use the new >> pass manager. Also there is lots of documentation updates >> that will be needed here. >> >> -Chandler >> >> PS: I'll be sending a note to cfe-dev as a "heads up" about >> this discussion as in some ways, the default flip is mostly a >> Clang default flip. But hopefully our doc updates will >> trigger this being "perceived" as the default for other >> frontends, and I'll try to reach out to other major frontends >> as well (Swift and Rust are on my radar, and I've already >> started talking with Philip Reames about their Falcon JIT). >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> >> >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> <http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev> > > -- > Hal Finkel > Lead, Compiler Technology and Programming Languages > Leadership Computing Facility > Argonne National Laboratory >-- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171025/d911c205/attachment.html>