Arthur Eubanks via llvm-dev
2020-Jun-08 23:29 UTC
[llvm-dev] optnone/skipping passes in the new pass manager
Hmm it looks like getting NPM to work with opt is non-trivial. Only a small portion of the opt functionality works with NPM :( On Mon, Jun 8, 2020 at 3:36 PM Robinson, Paul <paul.robinson at sony.com> wrote:> Maybe you could change the default PM in opt and see what fails? > > --paulr > > > > *From:* Arthur Eubanks <aeubanks at google.com> > *Sent:* Monday, June 8, 2020 5:52 PM > *To:* Robinson, Paul <paul.robinson at sony.com> > *Cc:* Chandler Carruth <chandlerc at gmail.com>; llvm-dev at lists.llvm.org > *Subject:* Re: [llvm-dev] optnone/skipping passes in the new pass manager > > > > > > > > On Mon, Jun 8, 2020 at 7:11 AM Robinson, Paul <paul.robinson at sony.com> > wrote: > > When the optnone design was being discussed, Chandler specifically > rejected having the pass manager involved in the decision (which was the > original proposed design). Assuming he still feels the same way now, if > the existing `skipFunction` calls aren’t being executed under the new pass > manager, then each pass that has that call will need to be modified > accordingly (added to the NPM path or moved to some common point). It > would be best if the `skipFunction` calls were handled consistently in all > passes so that it would become part of the normal pass boilerplate. > > Makes sense, thanks for the background. I'll see if there's a clean way to > make this functionality easy to use in the NPM. > > > > I suspect any `skipFunction` or opt-bisection tests have been written to > force the old pass manager, which is why defaulting to the new pass manager > doesn’t fail anywhere. > > I took a closer look at some optnone tests and they use opt instead of > clang. opt still defaults to the legacy pass manager regardless of clang's > default. > > --paulr > > > > *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *Arthur > Eubanks via llvm-dev > *Sent:* Sunday, June 7, 2020 7:59 PM > *To:* llvm-dev <llvm-dev at lists.llvm.org> > *Subject:* [llvm-dev] optnone/skipping passes in the new pass manager > > > > Looking through some of the remaining test failures under the new pass > manager, I've narrowed down one of the failures in GWPAsan(!) to the fact > that the new pass manager doesn't properly skip passes like the old pass > manager. For example, when a function is marked optnone, or when using > https://llvm.org/docs/OptBisect.html > <https://urldefense.com/v3/__https:/llvm.org/docs/OptBisect.html__;!!JmoZiZGBv3RvKRSx!t3zrtZFFWm0ifdWgL9SiWSNETodW3pMSJ8m8YWqK139cicFp_U1juO0D90-VinpUWg$> > . > > > > Lots of passes (e.g. SROA) will do the following under the legacy pass > manager: > > > > bool runOnFunction(Function &F) override { > if (skipFunction(F)) > return false; > > // do pass > > } > > > > What's the right way to proceed with this? There are 50-100 calls to > skipFunction() in legacy passes. This doesn't even account for other types > of IR units, like skipModule(Module&). > > > > I suppose it's possible to manually go in and add in the same check in the > new passes, but that seems tedious (and how do you test that at scale? > clearly there aren't many tests for it right now since check-llvm passes > under the new pass manager). An alternative of skipping passes at the pass > manager level would require marking each pass as necessary/optional (I > think...). > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200608/22cd68e2/attachment.html>
Johannes Doerfert via llvm-dev
2020-Jun-09 00:19 UTC
[llvm-dev] optnone/skipping passes in the new pass manager
On 6/8/20 6:29 PM, Arthur Eubanks via llvm-dev wrote:> Hmm it looks like getting NPM to work with opt is non-trivial. Only a small > portion of the opt functionality works with NPM :(I am very much looking forward to use the NPM by default but this sounds like a problem we need to fix first :(. You happen to have some "list" of things that are missing?> On Mon, Jun 8, 2020 at 3:36 PM Robinson, Paul <paul.robinson at sony.com> > wrote: > >> Maybe you could change the default PM in opt and see what fails? >> >> --paulr >> >> >> >> *From:* Arthur Eubanks <aeubanks at google.com> >> *Sent:* Monday, June 8, 2020 5:52 PM >> *To:* Robinson, Paul <paul.robinson at sony.com> >> *Cc:* Chandler Carruth <chandlerc at gmail.com>; llvm-dev at lists.llvm.org >> *Subject:* Re: [llvm-dev] optnone/skipping passes in the new pass manager >> >> >> >> >> >> >> >> On Mon, Jun 8, 2020 at 7:11 AM Robinson, Paul <paul.robinson at sony.com> >> wrote: >> >> When the optnone design was being discussed, Chandler specifically >> rejected having the pass manager involved in the decision (which was the >> original proposed design). Assuming he still feels the same way now, if >> the existing `skipFunction` calls aren’t being executed under the new pass >> manager, then each pass that has that call will need to be modified >> accordingly (added to the NPM path or moved to some common point). It >> would be best if the `skipFunction` calls were handled consistently in all >> passes so that it would become part of the normal pass boilerplate. >> >> Makes sense, thanks for the background. I'll see if there's a clean way to >> make this functionality easy to use in the NPM. >> >> >> >> I suspect any `skipFunction` or opt-bisection tests have been written to >> force the old pass manager, which is why defaulting to the new pass manager >> doesn’t fail anywhere. >> >> I took a closer look at some optnone tests and they use opt instead of >> clang. opt still defaults to the legacy pass manager regardless of clang's >> default. >> >> --paulr >> >> >> >> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *Arthur >> Eubanks via llvm-dev >> *Sent:* Sunday, June 7, 2020 7:59 PM >> *To:* llvm-dev <llvm-dev at lists.llvm.org> >> *Subject:* [llvm-dev] optnone/skipping passes in the new pass manager >> >> >> >> Looking through some of the remaining test failures under the new pass >> manager, I've narrowed down one of the failures in GWPAsan(!) to the fact >> that the new pass manager doesn't properly skip passes like the old pass >> manager. For example, when a function is marked optnone, or when using >> https://llvm.org/docs/OptBisect.html >> <https://urldefense.com/v3/__https:/llvm.org/docs/OptBisect.html__;!!JmoZiZGBv3RvKRSx!t3zrtZFFWm0ifdWgL9SiWSNETodW3pMSJ8m8YWqK139cicFp_U1juO0D90-VinpUWg$> >> . >> >> >> >> Lots of passes (e.g. SROA) will do the following under the legacy pass >> manager: >> >> >> >> bool runOnFunction(Function &F) override { >> if (skipFunction(F)) >> return false; >> >> // do pass >> >> } >> >> >> >> What's the right way to proceed with this? There are 50-100 calls to >> skipFunction() in legacy passes. This doesn't even account for other types >> of IR units, like skipModule(Module&). >> >> >> >> I suppose it's possible to manually go in and add in the same check in the >> new passes, but that seems tedious (and how do you test that at scale? >> clearly there aren't many tests for it right now since check-llvm passes >> under the new pass manager). An alternative of skipping passes at the pass >> manager level would require marking each pass as necessary/optional (I >> think...). >> >> > > _______________________________________________ > 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/20200608/103b5d5e/attachment.html>
Arthur Eubanks via llvm-dev
2020-Jun-09 00:49 UTC
[llvm-dev] optnone/skipping passes in the new pass manager
On Mon, Jun 8, 2020 at 5:21 PM Johannes Doerfert <johannesdoerfert at gmail.com> wrote:> > On 6/8/20 6:29 PM, Arthur Eubanks via llvm-dev wrote: > > Hmm it looks like getting NPM to work with opt is non-trivial. Only a small > portion of the opt functionality works with NPM :( > > I am very much looking forward to use the NPM by default but this sounds > like a problem we need to fix first :(. >I'll look into this some more.> You happen to have some "list" of things that are missing? >Not really, my process is fairly straightforward, set the ENABLE_EXPERIMENTAL_NEW_PASS_MANAGER CMake flag to TRUE, run check-all, and look at new failures. So far these two issues (skipping passes and opt) are the biggest issues I've stumbled across (and mostly by luck, like I said there were a couple failures in GwpAsan that unearthed this, at least for me). I'm still relatively new so I might be missing some existing list of NPM issues that somebody else more experienced has come up with?> > > On Mon, Jun 8, 2020 at 3:36 PM Robinson, Paul <paul.robinson at sony.com> <paul.robinson at sony.com> > wrote: > > > Maybe you could change the default PM in opt and see what fails? > > --paulr > > > > *From:* Arthur Eubanks <aeubanks at google.com> <aeubanks at google.com> > *Sent:* Monday, June 8, 2020 5:52 PM > *To:* Robinson, Paul <paul.robinson at sony.com> <paul.robinson at sony.com> > *Cc:* Chandler Carruth <chandlerc at gmail.com> <chandlerc at gmail.com>; llvm-dev at lists.llvm.org > *Subject:* Re: [llvm-dev] optnone/skipping passes in the new pass manager > > > > > > > > On Mon, Jun 8, 2020 at 7:11 AM Robinson, Paul <paul.robinson at sony.com> <paul.robinson at sony.com> > wrote: > > When the optnone design was being discussed, Chandler specifically > rejected having the pass manager involved in the decision (which was the > original proposed design). Assuming he still feels the same way now, if > the existing `skipFunction` calls aren’t being executed under the new pass > manager, then each pass that has that call will need to be modified > accordingly (added to the NPM path or moved to some common point). It > would be best if the `skipFunction` calls were handled consistently in all > passes so that it would become part of the normal pass boilerplate. > > Makes sense, thanks for the background. I'll see if there's a clean way to > make this functionality easy to use in the NPM. > > > > I suspect any `skipFunction` or opt-bisection tests have been written to > force the old pass manager, which is why defaulting to the new pass manager > doesn’t fail anywhere. > > I took a closer look at some optnone tests and they use opt instead of > clang. opt still defaults to the legacy pass manager regardless of clang's > default. > > --paulr > > > > *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> <llvm-dev-bounces at lists.llvm.org> *On Behalf Of *Arthur > Eubanks via llvm-dev > *Sent:* Sunday, June 7, 2020 7:59 PM > *To:* llvm-dev <llvm-dev at lists.llvm.org> <llvm-dev at lists.llvm.org> > *Subject:* [llvm-dev] optnone/skipping passes in the new pass manager > > > > Looking through some of the remaining test failures under the new pass > manager, I've narrowed down one of the failures in GWPAsan(!) to the fact > that the new pass manager doesn't properly skip passes like the old pass > manager. For example, when a function is marked optnone, or when usinghttps://llvm.org/docs/OptBisect.html<https://urldefense.com/v3/__https:/llvm.org/docs/OptBisect.html__;!!JmoZiZGBv3RvKRSx!t3zrtZFFWm0ifdWgL9SiWSNETodW3pMSJ8m8YWqK139cicFp_U1juO0D90-VinpUWg$> <https://urldefense.com/v3/__https:/llvm.org/docs/OptBisect.html__;!!JmoZiZGBv3RvKRSx!t3zrtZFFWm0ifdWgL9SiWSNETodW3pMSJ8m8YWqK139cicFp_U1juO0D90-VinpUWg$> > . > > > > Lots of passes (e.g. SROA) will do the following under the legacy pass > manager: > > > > bool runOnFunction(Function &F) override { > if (skipFunction(F)) > return false; > > // do pass > > } > > > > What's the right way to proceed with this? There are 50-100 calls to > skipFunction() in legacy passes. This doesn't even account for other types > of IR units, like skipModule(Module&). > > > > I suppose it's possible to manually go in and add in the same check in the > new passes, but that seems tedious (and how do you test that at scale? > clearly there aren't many tests for it right now since check-llvm passes > under the new pass manager). An alternative of skipping passes at the pass > manager level would require marking each pass as necessary/optional (I > think...). > > > > > _______________________________________________ > LLVM Developers mailing listllvm-dev at lists.llvm.orghttps://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/20200608/07a3d0d0/attachment.html>