ing order in which paths out of the array.
>
>
> Jeff
Please check my explanation in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78879#c11
Thanks!
Yuan, Pengfei
Hi,
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78879
There are some other invocations of unordered_remove in
tree-ssa-threadupdate.c, which may also need to be replaced
with ordered_remove.
Regards,
Yuan, Pengfei
2016-12-22 Yuan Pengfei <y...@pku.edu
> On Mon, Oct 10, 2016 at 4:23 AM, Yuan, Pengfei <y...@pku.edu.cn> wrote:
> > Hi,
> >
> > What is the decision on this patch?
> > https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01041.html
>
> Honza approved the patch already.
>
> Richard.
Do I need
Hi,
What is the decision on this patch?
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01041.html
Regards,
Yuan, Pengfei
> A new patch for trunk is attached.
>
> Regards,
> Yuan, Pengfei
>
>
> 2016-09-16 Yuan Pengfei <y...@pku.edu.cn>
>
> * doc/in
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=14,
the code size reduction is only 1.1%.
Yuan, Pengfei
> Richard.
>
> > Richard.
Delaying inlining from early inlining to IPA inlining can save size because
profile
feedback is effective at IPA inlining and inlining of cold functions can be
avoided.
Otherwise, inlining done at early inlining can not be canceled later.
Yuan, Pengfei
> Richard.
>
> > Yuan, Pengfei
ram inline-unit-growth only affects pass_ipa_inline. However, the code
size reduction achieved with my patch is from pass_early_inline.
Yuan, Pengfei
ay make it profile specific in
> > > future..
> > >
> > > Honza
> > > >
> > > > Thanks,
> > > > Richard.
> >
> > A new patch for trunk is attached.
> >
> > Regards,
> > Yuan, Pen
, you are right that you do not know if this particular function will get
> profile (forgot about that). Still, please use two params - it is more
> consistent with what we have now and we may make it profile specific in
> future..
>
> Honza
> >
> > Thanks,
> > Richard.
A
bal property of program. It may or may not be
> available for given function, while params are global.
Whether profile is available for specific functions is not important here
because
profile is loaded after pass_early_inline. Therefore I think setting the param
globally is fine.
> Eve
.07-1.750.32
4 1.41-1.50 -0.09
5 1.02-1.23 -0.21
6 1.00-1.000.00
14 0.00-0.34 -0.34
Therefore, I think param=2 is the best choice.
Is the attached patch OK?
Regards,
Yuan, Pengfei
gcc/ChangeLog
14 ... didn't know it's _that_ high currently ;)).
> What's the
> value that crosses the boundary of diminishing returns regarding to code-size
> improvements for you?
>
> Richard.
>
I see. This procedure may take some time since profile data can not be reused.
Yuan, Pengfei
simply
> adjust the PARAM_EARLY_INLINING_INSNS default accordingly when FDO is
> enabled?
Setting PARAM_EARLY_INLINING_INSNS to 0 when FDO is enabled should be
equivalent to my patch.
Regards,
Yuan, Pengfei
> I'll let Honza also double-check the condition detecting FDO (it looks
>
ent is conducted with GCC 5. There is segmentation
fault when starting Firefox instrumented by GCC 6. GCC 7 encounters ICE when
building Firefox.
Regards,
Yuan, Pengfei
gcc/ChangeLog:
* ipa-inline.c (want_early_inline_function_p): Be more conservative
if FDO is enabled.
diff --
15 matches
Mail list logo
