Modi Mo via llvm-dev
2020-Sep-10 00:55 UTC
[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. And yeah using PGSO is selecting optsize while this change is selecting optnone. On 9/9/20, 10:58 AM, "llvm-dev on behalf of Tobias Hieta via llvm-dev" <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces at lists.llvm.org> on behalf of llvm-dev at lists.llvm.org<mailto: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<mailto: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<mailto: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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200910/ffc47f4d/attachment.html>
Wenlei He via llvm-dev
2020-Sep-10 04:23 UTC
[llvm-dev] [RFC] New Feature Proposal: De-Optimizing Cold Functions using PGO Info
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. On 9/9/20, 10:58 AM, "llvm-dev on behalf of Tobias Hieta via llvm-dev" <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces at lists.llvm.org> on behalf of llvm-dev at lists.llvm.org<mailto: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<mailto: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<mailto: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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200910/a0c90335/attachment.html>
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>