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

On Wed, 9 Sep 2020 at 19:26, Nemanja Ivanovic <nemanja.i.ibm at gmail.com>
wrote:
> - Default (i.e. no -profile-deopt-cold): do nothing
> - Option with no arg (i.e. -profile-deopt-cold): add attribute only to
> functions that have an execution count of zero
> - Option with an arg (i.e. -profile-deopt-cold=<N>): add attribute to
> functions that account for <N>% of total execution counts
>
I see. This looks confusing to me, but perhaps it's just me.

Though, I'm not sure we can get this behaviour from the same flag, as you
need to provide a default value if the flag isn't passed (usually boolean
or integer, not both).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200909/9f840692/attachment.html>

On Wed, Sep 9, 2020 at 3:10 PM Renato Golin via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> On Wed, 9 Sep 2020 at 19:26, Nemanja Ivanovic <nemanja.i.ibm at
gmail.com>
> wrote:
>
>> - Default (i.e. no -profile-deopt-cold): do nothing
>> - Option with no arg (i.e. -profile-deopt-cold): add attribute only to
>> functions that have an execution count of zero
>> - Option with an arg (i.e. -profile-deopt-cold=<N>): add
attribute to
>> functions that account for <N>% of total execution counts
>>
>
> I see. This looks confusing to me, but perhaps it's just me.
>
It's not just you. :)  Assuming "account for <N>% of total
execution
counts" means "account for <N>% *or less* of total execution
counts," then
it seems like the proposed -profile-deopt-cold does the same thing as
-profile-deopt-cold=0.

Also, for build-system-friendliness, IMHO every positive option should have
a negative option — i.e., the default behavior should be regainable via an
option such as -profile-no-deopt-cold.  (Or -fno-profile-deopt-cold, if
there was a missing `f` in all of the above.)  That seems easier to do if
the whole thing is controlled by just one option instead of two.

my $.02,
–Arthur
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200909/6ea41f91/attachment.html>

Hi All,

On Wed, Sep 9, 2020 at 12:23 PM Arthur O'Dwyer via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> On Wed, Sep 9, 2020 at 3:10 PM Renato Golin via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> On Wed, 9 Sep 2020 at 19:26, Nemanja Ivanovic <nemanja.i.ibm at
gmail.com>
>> wrote:
>>
>>> - Default (i.e. no -profile-deopt-cold): do nothing
>>> - Option with no arg (i.e. -profile-deopt-cold): add attribute only
to
>>> functions that have an execution count of zero
>>> - Option with an arg (i.e. -profile-deopt-cold=<N>): add
attribute to
>>> functions that account for <N>% of total execution counts
>>>
>>
>> I see. This looks confusing to me, but perhaps it's just me.
>>
>
> It's not just you. :)  Assuming "account for <N>% of total
execution
> counts" means "account for <N>% *or less* of total
execution counts,"
> then it seems like the proposed -profile-deopt-cold does the same thing
> as -profile-deopt-cold=0.
>
> Also, for build-system-friendliness, IMHO every positive option should
> have a negative option — i.e., the default behavior should be regainable
> via an option such as -profile-no-deopt-cold.  (Or -fno-profile-deopt-cold,
> if there was a missing `f` in all of the above.)  That seems easier to do
> if the whole thing is controlled by just one option instead of two.
>
Actually there has always been a `-fno-profile-deopt-cold` driver flag in
my second Phabricator review (D87338).
But to sum up, I think it's a good idea to have only one driver flag, or
even one LLVM CLI option.

>
> my $.02,
> –Arthur
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-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/20200909/bbcd0444/attachment.html>