Hiroshi Yamauchi via llvm-dev
2020-Sep-10 16:11 UTC
[llvm-dev] [RFC] New Feature Proposal: De-Optimizing Cold Functions using PGO Info
On Wed, Sep 9, 2020 at 9:23 PM Wenlei He via llvm-dev < llvm-dev at lists.llvm.org> wrote:> I think calling PGSO size opt is probably a bit misleading though. It’s > more of an adaptive opt strategy, and it can improve performance too due to > better locality. We have something similar internally for selecting opt > level based on profile hotness too under AutoFDO. > > > > Perhaps similar implementations can all be unified under a profile guided > “adaptive optimization” framework to avoid duplication: > > - A unified way of setting hot/cold cutoff percentile (e.g. through > PSI that’s already used by all PGO/FDO). > - A unified way of selecting opt strategy for cold functions: default, > none, size, minsize. > > > > Thanks, > > Wenlei > > > > *From: *llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Modi Mo > via llvm-dev <llvm-dev at lists.llvm.org> > *Reply-To: *Modi Mo <modimo at fb.com> > *Date: *Wednesday, September 9, 2020 at 5:55 PM > *To: *Tobias Hieta <tobias at plexapp.com>, Renato Golin <rengolin at gmail.com> > *Cc: *"ddevienne at gmail.com" <ddevienne at gmail.com>, llvm-dev < > llvm-dev at lists.llvm.org>, "cfe-dev (cfe-dev at lists.llvm.org)" < > cfe-dev at lists.llvm.org> > *Subject: *Re: [llvm-dev] [RFC] New Feature Proposal: De-Optimizing Cold > Functions using PGO Info > > > > FYI David is referring to PGSO (profile-guided size optimization) as it > exists directly under that name, see: https://reviews.llvm.org/D67120 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D67120&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=KfYo542rDdZQGClmgz-RBw&m=tscXcy0bnqeZPQHl9SiPfgvfUizD33tNurQecbRunKg&s=RvBQN7FNwjsvLgJgV9jlOUCrkLubfH6CtcALRdXOYao&e=>. > And yeah using PGSO is selecting optsize while this change is selecting > optnone. >PGSO looks at the block-level profile, too.> > On 9/9/20, 10:58 AM, "llvm-dev on behalf of Tobias Hieta via llvm-dev" < > llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org> > wrote: > > > > Would it make sense to have a flag to select optnone or optsize? We would > probably also do the tradeoff for a smaller binary. > > > > On Wed, Sep 9, 2020, 19:28 Renato Golin <rengolin at gmail.com> wrote: > > On Wed, 9 Sep 2020 at 18:15, Min-Yih Hsu via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > David mentioned in D87337 that LLVM has used similar techniques on code > size (not sure what he was referencing, my guess will be something related > to hot-cold code splitting). > > > > IIUC, it's just using optsize instead of optnone. The idea is that, if the > code really doesn't run often/at all, then the performance impact of > reducing the size is negligible, but the size impact is considerable. > > > > I'd wager that optsize could even be faster than optnone, as it would > delete a lot of useless code... but not noticeable, as it wouldn't run much. > > > > This is an idea that we (Verona Language) are interested in, too. > > _______________________________________________ > 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/20200910/022f4334/attachment.html>
Min-Yih Hsu via llvm-dev
2020-Sep-10 17:22 UTC
[llvm-dev] [RFC] New Feature Proposal: De-Optimizing Cold Functions using PGO Info
Hi, Thanks for all the feedback related to code size.>From my understanding, the current PGSO (D59514, D67120) has two parts:1. Adding a new llvm::shouldOptimizeForSize framework that leverages BFI and PSI to provide block level and function level assessments on whether we should optimize for size. 2. In Passes (mostly MachinePasses), they'll change certain behaviors (e.g. whether adding pads or not) if llvm::shouldOptimizeForSize returns true OR there is an `optsize` or `minsize` attribute I totally agree with Wenlei that (somewhere in the future) we should have a unified FDO framework for both code size and compilation time. And I think Renato and Tobias's suggestions to do the same thing for size-oriented attributes (i.e. `minsize` and `optsize`) is the low-hanging fruit we can support in a short time. Engineering-wised I'll prefer to send out a separate review for the size-oriented attributes work, since `minsize` / `optsize` are kind of in conflict with `optnone` so I don't think it's a good idea to put them into one flag / feature set. Best, Min On Thu, Sep 10, 2020 at 9:18 AM Hiroshi Yamauchi via llvm-dev < llvm-dev at lists.llvm.org> wrote:> > > On Wed, Sep 9, 2020 at 9:23 PM Wenlei He via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I think calling PGSO size opt is probably a bit misleading though. It’s >> more of an adaptive opt strategy, and it can improve performance too due to >> better locality. We have something similar internally for selecting opt >> level based on profile hotness too under AutoFDO. >> >> >> >> Perhaps similar implementations can all be unified under a profile guided >> “adaptive optimization” framework to avoid duplication: >> >> - A unified way of setting hot/cold cutoff percentile (e.g. through >> PSI that’s already used by all PGO/FDO). >> - A unified way of selecting opt strategy for cold functions: >> default, none, size, minsize. >> >> >> >> Thanks, >> >> Wenlei >> >> >> >> *From: *llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Modi Mo >> via llvm-dev <llvm-dev at lists.llvm.org> >> *Reply-To: *Modi Mo <modimo at fb.com> >> *Date: *Wednesday, September 9, 2020 at 5:55 PM >> *To: *Tobias Hieta <tobias at plexapp.com>, Renato Golin <rengolin at gmail.com >> > >> *Cc: *"ddevienne at gmail.com" <ddevienne at gmail.com>, llvm-dev < >> llvm-dev at lists.llvm.org>, "cfe-dev (cfe-dev at lists.llvm.org)" < >> cfe-dev at lists.llvm.org> >> *Subject: *Re: [llvm-dev] [RFC] New Feature Proposal: De-Optimizing Cold >> Functions using PGO Info >> >> >> >> FYI David is referring to PGSO (profile-guided size optimization) as it >> exists directly under that name, see: https://reviews.llvm.org/D67120 >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D67120&d=DwMGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=KfYo542rDdZQGClmgz-RBw&m=tscXcy0bnqeZPQHl9SiPfgvfUizD33tNurQecbRunKg&s=RvBQN7FNwjsvLgJgV9jlOUCrkLubfH6CtcALRdXOYao&e=>. >> And yeah using PGSO is selecting optsize while this change is selecting >> optnone. >> > > PGSO looks at the block-level profile, too. > > >> >> On 9/9/20, 10:58 AM, "llvm-dev on behalf of Tobias Hieta via llvm-dev" < >> llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org> >> wrote: >> >> >> >> Would it make sense to have a flag to select optnone or optsize? We would >> probably also do the tradeoff for a smaller binary. >> >> >> >> On Wed, Sep 9, 2020, 19:28 Renato Golin <rengolin at gmail.com> wrote: >> >> On Wed, 9 Sep 2020 at 18:15, Min-Yih Hsu via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >> David mentioned in D87337 that LLVM has used similar techniques on code >> size (not sure what he was referencing, my guess will be something related >> to hot-cold code splitting). >> >> >> >> IIUC, it's just using optsize instead of optnone. The idea is that, if >> the code really doesn't run often/at all, then the performance impact of >> reducing the size is negligible, but the size impact is considerable. >> >> >> >> I'd wager that optsize could even be faster than optnone, as it would >> delete a lot of useless code... but not noticeable, as it wouldn't run much. >> >> >> >> This is an idea that we (Verona Language) are interested in, too. >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-- Min-Yih Hsu Ph.D Student in ICS Department, University of California, Irvine (UCI). -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200910/3fd149ec/attachment-0001.html>
Renato Golin via llvm-dev
2020-Sep-10 17:54 UTC
[llvm-dev] [RFC] New Feature Proposal: De-Optimizing Cold Functions using PGO Info
On Thu, 10 Sep 2020 at 18:22, Min-Yih Hsu <minyihh at uci.edu> wrote:> I totally agree with Wenlei that (somewhere in the future) we should have > a unified FDO framework for both code size and compilation time. And I > think Renato and Tobias's suggestions to do the same thing for > size-oriented attributes (i.e. `minsize` and `optsize`) is the > low-hanging fruit we can support in a short time. > Engineering-wised I'll prefer to send out a separate review for the > size-oriented attributes work, since `minsize` / `optsize` are kind of in > conflict with `optnone` so I don't think it's a good idea to put them into > one flag / feature set. >I'm happy for this unification to happen at a later stage. Just not too long later. I worry exposing the flags will get people to use it and then we'll change it. The longer we leave it, the more people will be hit by the subtle change. Worse still if we release with one behaviour now and then with a different behaviour in the next release. Having conditional paths in build systems for different versions of the compiler isn't fun. --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200910/06279581/attachment.html>