[llvm-dev] [RFC] New Feature Proposal: De-Optimizing Cold Functions using PGO Info

Wenlei He via llvm-dev
Thu, 10 Sep 2020 04:23:28 -0000

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>