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

[Min-Yih Hsu via cfe-dev]

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/cfe-dev/attachments/20200910/3fd149ec/attachment-0001.html>