Hi,
May I ask if there is any decision?
Regards,
Yuan, Pengfei
> > > I also like a new param better as it avoids a new magic constant and
> > > makes playing with
> > > it easier (your patch removes the ability to do statistics like you did
> > > via the
> > > early-inlining-insns parameter by
> > Btw, It occurs to me that then win in code-size might be purely due to the
> > smaller base value for the TU size we use to compute the maximum unit
> > growth with ... any idea how to improve it on this side? Say, computing
> > the TU size before early optimization (uh, probably not ...)
> >
> >> > Btw, It occurs to me that then win in code-size might be purely due to
> >> > the
> >> > smaller base value for the TU size we use to compute the maximum unit
> >> > growth with ... any idea how to improve it on this side? Say, computing
> >> > the TU size before early optimization (uh, pr
On Tue, Sep 20, 2016 at 1:57 PM, Yuan, Pengfei wrote:
>> > Btw, It occurs to me that then win in code-size might be purely due to the
>> > smaller base value for the TU size we use to compute the maximum unit
>> > growth with ... any idea how to improve it on this side? Say, computing
>> > the TU
> > Btw, It occurs to me that then win in code-size might be purely due to the
> > smaller base value for the TU size we use to compute the maximum unit
> > growth with ... any idea how to improve it on this side? Say, computing
> > the TU size before early optimization (uh, probably not ...)
> >
On Tue, Sep 20, 2016 at 1:31 PM, Richard Biener
wrote:
> On Fri, Sep 16, 2016 at 2:00 PM, Jan Hubicka wrote:
>>> > > I also like a new param better as it avoids a new magic constant and
>>> > > makes playing with
>>> > > it easier (your patch removes the ability to do statistics like you did
>>>
On Fri, Sep 16, 2016 at 2:00 PM, Jan Hubicka wrote:
>> > > I also like a new param better as it avoids a new magic constant and
>> > > makes playing with
>> > > it easier (your patch removes the ability to do statistics like you did
>> > > via the
>> > > early-inlining-insns parameter by forcing
> > > > I also like a new param better as it avoids a new magic constant and
> > > > makes playing with
> > > > it easier (your patch removes the ability to do statistics like you did
> > > > via the
> > > > early-inlining-insns parameter by forcing it to two).
> > >
> > > Hmm, you are right that
> > > I also like a new param better as it avoids a new magic constant and
> > > makes playing with
> > > it easier (your patch removes the ability to do statistics like you did
> > > via the
> > > early-inlining-insns parameter by forcing it to two).
> >
> > Hmm, you are right that you do not kn
> > I also like a new param better as it avoids a new magic constant and
> > makes playing with
> > it easier (your patch removes the ability to do statistics like you did via
> > the
> > early-inlining-insns parameter by forcing it to two).
>
> Hmm, you are right that you do not know if this par
> On Fri, Sep 16, 2016 at 10:50 AM, Yuan, Pengfei wrote:
> >> > Here are the results:
> >> >
> >> > Param Size (GCC5)Time (GCC5) Time (GCC7)
> >> > 0 44686265 (-8.26%) 58.772s 66.332s
> >> > 1 45692793 (-6.19%) 40.684s 39.220s
> >> > 2 45556185 (-6.47%) 35.292
On Fri, Sep 16, 2016 at 10:50 AM, Yuan, Pengfei wrote:
>> > Here are the results:
>> >
>> > Param Size (GCC5)Time (GCC5) Time (GCC7)
>> > 0 44686265 (-8.26%) 58.772s 66.332s
>> > 1 45692793 (-6.19%) 40.684s 39.220s
>> > 2 45556185 (-6.47%) 35.292s 34.328s
> > Here are the results:
> >
> > Param Size (GCC5)Time (GCC5) Time (GCC7)
> > 0 44686265 (-8.26%) 58.772s 66.332s
> > 1 45692793 (-6.19%) 40.684s 39.220s
> > 2 45556185 (-6.47%) 35.292s 34.328s
> > 3 46251049 (-5.05%) 28.820s 27.136s
> > 4
>
> Here are the results:
>
> Param Size (GCC5)Time (GCC5) Time (GCC7)
> 0 44686265 (-8.26%) 58.772s 66.332s
> 1 45692793 (-6.19%) 40.684s 39.220s
> 2 45556185 (-6.47%) 35.292s 34.328s
> 3 46251049 (-5.05%) 28.820s 27.136s
> 4 47028873 (-
> > Setting PARAM_EARLY_INLINING_INSNS to 0 when FDO is enabled should be
> > equivalent to my patch.
>
> Yes. This means it's easy to experiment with other values than zero.
> Basically
> early inlining is supposed to remove abstraction penalty to
>
> a) reduce FDO instrumentation overhead
>
> Yes. This means it's easy to experiment with other values than zero.
> Basically
> early inlining is supposed to remove abstraction penalty to
>
> a) reduce FDO instrumentation overhead
> b) get more realistic size estimates for the inliner
>
> a) was particularly important back in time fo
On Thu, Sep 15, 2016 at 2:21 AM, Yuan, Pengfei wrote:
>> I think the approach is reasonable though it might still have
>> interesting effects on
>> optimization for very small growth. So for further experimenting it
>> would be nice
>
> Test it on SPEC CPU with FDO enabled?
>
>> to have a separat
> I think the approach is reasonable though it might still have
> interesting effects on
> optimization for very small growth. So for further experimenting it
> would be nice
Test it on SPEC CPU with FDO enabled?
> to have a separate PARAM_EARLY_FDO_INLINING_INSNS or maybe simply
> adjust the PA
On Sat, Sep 10, 2016 at 8:04 AM, Yuan, Pengfei wrote:
> Hi,
>
> Previously I have sent a patch on profile based option tuning:
> https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01377.html
>
> According to Richard Biener's advice, I try investigating where the code size
> reduction comes from. After
19 matches
Mail list logo
