> Ok, that sounds good. Here is the new patch. Is this ok for trunk if
> testing (bootstrap regression and lto profiledbootstrap) succeeds?
>
> Thanks,
> Teresa
>
> 2013-11-13 Teresa Johnson
>
> * predict.c (drop_profile): Error is currently too strict.
> (handle_missing_profi
On Tue, Nov 12, 2013 at 2:35 PM, Jan Hubicka wrote:
>> On Tue, Nov 12, 2013 at 1:33 PM, Jan Hubicka wrote:
>> >> More info on the lto bootstrap failure:
>> >>
>> >> /usr/local/google/home/tejohnson/gcc_trunk_9/libiberty/pex-unix.c:790:1:
>> >> warning: Missing counts for called function pex_child
> On Tue, Nov 12, 2013 at 1:33 PM, Jan Hubicka wrote:
> >> More info on the lto bootstrap failure:
> >>
> >> /usr/local/google/home/tejohnson/gcc_trunk_9/libiberty/pex-unix.c:790:1:
> >> warning: Missing counts for called function pex_child_error.isra.1/73
> >> [enabled by default]
> >> }
> >>
>
On Tue, Nov 12, 2013 at 1:33 PM, Jan Hubicka wrote:
>> More info on the lto bootstrap failure:
>>
>> /usr/local/google/home/tejohnson/gcc_trunk_9/libiberty/pex-unix.c:790:1:
>> warning: Missing counts for called function pex_child_error.isra.1/73
>> [enabled by default]
>> }
>>
>> This is an erro
> More info on the lto bootstrap failure:
>
> /usr/local/google/home/tejohnson/gcc_trunk_9/libiberty/pex-unix.c:790:1:
> warning: Missing counts for called function pex_child_error.isra.1/73
> [enabled by default]
> }
>
> This is an error handling routine that invokes _exit. Looking at the
> ipa
On Tue, Nov 12, 2013 at 11:08 AM, Teresa Johnson wrote:
> On Mon, Nov 11, 2013 at 9:17 AM, Teresa Johnson wrote:
>> On Mon, Nov 11, 2013 at 9:13 AM, Jan Hubicka wrote:
On Mon, Nov 11, 2013 at 8:22 AM, Jan Hubicka wrote:
>> I have a warning like that already in drop_profile(). Is that
On Mon, Nov 11, 2013 at 9:17 AM, Teresa Johnson wrote:
> On Mon, Nov 11, 2013 at 9:13 AM, Jan Hubicka wrote:
>>> On Mon, Nov 11, 2013 at 8:22 AM, Jan Hubicka wrote:
>>> >> I have a warning like that already in drop_profile(). Is that
>>> >
>>> > I think it should be warning (or silent) for COMDA
On Mon, Nov 11, 2013 at 9:13 AM, Jan Hubicka wrote:
>> On Mon, Nov 11, 2013 at 8:22 AM, Jan Hubicka wrote:
>> >> I have a warning like that already in drop_profile(). Is that
>> >
>> > I think it should be warning (or silent) for COMDAT and error/note for
>> > other functions (depending on flag_p
> On Mon, Nov 11, 2013 at 8:22 AM, Jan Hubicka wrote:
> >> I have a warning like that already in drop_profile(). Is that
> >
> > I think it should be warning (or silent) for COMDAT and error/note for
> > other functions (depending on flag_profile_correction).
> > I guess drop_profile is better pla
On Mon, Nov 11, 2013 at 8:22 AM, Jan Hubicka wrote:
>> I have a warning like that already in drop_profile(). Is that
>
> I think it should be warning (or silent) for COMDAT and error/note for
> other functions (depending on flag_profile_correction).
> I guess drop_profile is better place for it in
> I have a warning like that already in drop_profile(). Is that
I think it should be warning (or silent) for COMDAT and error/note for
other functions (depending on flag_profile_correction).
I guess drop_profile is better place for it indeed.
> sufficient? Also, Steven Bosscher suggested putting
On Mon, Nov 11, 2013 at 7:23 AM, Jan Hubicka wrote:
>> 2013-11-08 Teresa Johnson
>> Jan Hubicka
>>
>> * predict.c (drop_profile): New function.
>> (handle_missing_profiles): Ditto.
>> (counts_to_freqs): Don't overwrite estimated frequencies
>> when
> 2013-11-08 Teresa Johnson
> Jan Hubicka
>
> * predict.c (drop_profile): New function.
> (handle_missing_profiles): Ditto.
> (counts_to_freqs): Don't overwrite estimated frequencies
> when function has no profile counts.
> * predict.h (hand
On Sun, Nov 10, 2013 at 1:08 PM, Eric Botcazou wrote:
>> > +
>> > + profile_status_for_function (fn)
>> > + = (flag_guess_branch_prob ? PROFILE_GUESSED : PROFILE_ABSENT);
>> > + node->frequency
>> > + = hot ? NODE_FREQUENCY_HOT : NODE_FREQUENCY_NORMAL;
>>
>> In GCC code style the = goes
> > +
> > + profile_status_for_function (fn)
> > + = (flag_guess_branch_prob ? PROFILE_GUESSED : PROFILE_ABSENT);
> > + node->frequency
> > + = hot ? NODE_FREQUENCY_HOT : NODE_FREQUENCY_NORMAL;
>
> In GCC code style the = goes at the end of the line:
>
> profile_status_for_function
On Fri, Nov 8, 2013 at 10:58 PM, Teresa Johnson wrote:
> +static void
> +drop_profile (struct cgraph_node *node, bool hot)
> +{
> + struct function *fn = DECL_STRUCT_FUNCTION (node->decl);
> +
> + if (dump_file)
> +fprintf (dump_file,
> + "Dropping 0 profile for %s/%i. %s based o
On Tue, Nov 5, 2013 at 6:02 AM, Teresa Johnson wrote:
> Ping.
> Thanks, Teresa
>
I updated the patch to include the follow-on work to apply call counts
to 0-weight functions using the estimated frequencies when inlining.
This helps avoid 0-weight blocks of inlined code which are
particularly bad
Ping.
Thanks, Teresa
On Wed, Oct 30, 2013 at 1:15 PM, Teresa Johnson wrote:
> On Fri, Oct 18, 2013 at 2:17 PM, Jan Hubicka wrote:
>>> Here is the patch updated to use the new parameter from r203830.
>>> Passed bootstrap and regression tests.
>>>
>>> 2013-10-18 Jan Hubicka
>>> Tere
On Fri, Oct 18, 2013 at 2:17 PM, Jan Hubicka wrote:
>> Here is the patch updated to use the new parameter from r203830.
>> Passed bootstrap and regression tests.
>>
>> 2013-10-18 Jan Hubicka
>> Teresa Johnson
>>
>> * predict.c (handle_missing_profiles): New function.
>>
> Here is the patch updated to use the new parameter from r203830.
> Passed bootstrap and regression tests.
>
> 2013-10-18 Jan Hubicka
> Teresa Johnson
>
> * predict.c (handle_missing_profiles): New function.
> (counts_to_freqs): Don't overwrite estimated frequenc
Here is the patch updated to use the new parameter from r203830.
Passed bootstrap and regression tests.
2013-10-18 Jan Hubicka
Teresa Johnson
* predict.c (handle_missing_profiles): New function.
(counts_to_freqs): Don't overwrite estimated frequencies
when
On Tue, Oct 15, 2013 at 3:39 PM, Teresa Johnson wrote:
> On Tue, Oct 15, 2013 at 2:57 PM, Jan Hubicka wrote:
>>> On Tue, Oct 15, 2013 at 2:03 PM, Jan Hubicka wrote:
>>> >> Yes, that would work. So let's discard this patch because the fix for
>>> >> comdat can also fix this problem.
>>> >
>>> > U
On Tue, Oct 15, 2013 at 2:57 PM, Jan Hubicka wrote:
>> On Tue, Oct 15, 2013 at 2:03 PM, Jan Hubicka wrote:
>> >> Yes, that would work. So let's discard this patch because the fix for
>> >> comdat can also fix this problem.
>> >
>> > Unforutnately ipa-profile-estimate is an IPA pass and as such it
> On Tue, Oct 15, 2013 at 2:03 PM, Jan Hubicka wrote:
> >> Yes, that would work. So let's discard this patch because the fix for
> >> comdat can also fix this problem.
> >
> > Unforutnately ipa-profile-estimate is an IPA pass and as such it does
> > not have access to profile_status_to_function.
>
On Tue, Oct 15, 2013 at 2:03 PM, Jan Hubicka wrote:
>> Yes, that would work. So let's discard this patch because the fix for
>> comdat can also fix this problem.
>
> Unforutnately ipa-profile-estimate is an IPA pass and as such it does
> not have access to profile_status_to_function.
I see. I was
> Yes, that would work. So let's discard this patch because the fix for
> comdat can also fix this problem.
Unforutnately ipa-profile-estimate is an IPA pass and as such it does
not have access to profile_status_to_function.
You can probably just factor this out into a function that can be called
Yes, that would work. So let's discard this patch because the fix for
comdat can also fix this problem.
Thanks,
Dehao
On Tue, Oct 15, 2013 at 8:42 AM, Teresa Johnson wrote:
> I'm planning to move it to ipa_profile (pass ipa-profile_estimate) and
> doing it iteratively. Would that location work?
I'm planning to move it to ipa_profile (pass ipa-profile_estimate) and
doing it iteratively. Would that location work?
Teresa
On Tue, Oct 15, 2013 at 8:40 AM, Dehao Chen wrote:
> Thanks for the pointer to Honza's patch. The patch does exactly what I
> need. But it only resides in the instrumenta
Thanks for the pointer to Honza's patch. The patch does exactly what I
need. But it only resides in the instrumentation based FDO path. Can
we move the code to more common place (like rebuild_cgraph_edges)?
Thanks,
Dehao
On Tue, Oct 15, 2013 at 7:59 AM, Teresa Johnson wrote:
> On Mon, Oct 14, 20
On Mon, Oct 14, 2013 at 3:26 PM, Dehao Chen wrote:
> On Mon, Oct 14, 2013 at 2:50 PM, Jan Hubicka wrote:
>>> For my test case, the entire inline instance is optimized away, so
>>> there is no info about it in the profile. I can do some fixup in the
>>> rebuild_cgraph_edge though.
>>
>> Yep, I und
The patch updated:
Index: gcc/cgraph.c
===
--- gcc/cgraph.c (revision 203609)
+++ gcc/cgraph.c (working copy)
@@ -877,6 +877,10 @@ cgraph_create_edge_1 (struct cgraph_node *caller,
if (call_stmt && caller->call_site_hash)
cgra
On Mon, Oct 14, 2013 at 2:50 PM, Jan Hubicka wrote:
>> For my test case, the entire inline instance is optimized away, so
>> there is no info about it in the profile. I can do some fixup in the
>> rebuild_cgraph_edge though.
>
> Yep, I understand that. In this case we should turn PROFILE_READ to
On Mon, Oct 14, 2013 at 3:04 PM, Xinliang David Li wrote:
> On Mon, Oct 14, 2013 at 2:34 PM, Dehao Chen wrote:
>> For my test case, the entire inline instance is optimized away,
>
> do you mean there is no out of line instance for the target function
> in the profile binary?
Yes, and there is no
On Mon, Oct 14, 2013 at 2:34 PM, Dehao Chen wrote:
> For my test case, the entire inline instance is optimized away,
do you mean there is no out of line instance for the target function
in the profile binary?
David
> so
> there is no info about it in the profile. I can do some fixup in the
> re
> For my test case, the entire inline instance is optimized away, so
> there is no info about it in the profile. I can do some fixup in the
> rebuild_cgraph_edge though.
Yep, I understand that. In this case we should turn PROFILE_READ to
PROFILE_GUESSED
and guess the profile when we detect this
For my test case, the entire inline instance is optimized away, so
there is no info about it in the profile. I can do some fixup in the
rebuild_cgraph_edge though.
Dehao
On Mon, Oct 14, 2013 at 2:27 PM, Xinliang David Li wrote:
> Is it possible to update the callee node summary after profile
> a
Is it possible to update the callee node summary after profile
annotate (using information from inline instances which are not
inlined in early inline)?
David
On Mon, Oct 14, 2013 at 2:18 PM, Dehao Chen wrote:
> On Mon, Oct 14, 2013 at 12:49 PM, Jan Hubicka wrote:
>>> Not for instrumented FDO (
On Mon, Oct 14, 2013 at 12:49 PM, Jan Hubicka wrote:
>> Not for instrumented FDO (not as I know of). But for AutoFDO, this
>> could be a potential risk because some callee is marked unlikely
>> executed simply because they are inlined and eliminated in the O2
>> binary. But in ipa-inline it will n
> Not for instrumented FDO (not as I know of). But for AutoFDO, this
> could be a potential risk because some callee is marked unlikely
> executed simply because they are inlined and eliminated in the O2
> binary. But in ipa-inline it will not get inlined because the edge is
> not hot from cgraph_m
Not for instrumented FDO (not as I know of). But for AutoFDO, this
could be a potential risk because some callee is marked unlikely
executed simply because they are inlined and eliminated in the O2
binary. But in ipa-inline it will not get inlined because the edge is
not hot from cgraph_maybe_hot_e
Looks like there is some inconsistency between edge hotness and callee
frequency?
David
On Mon, Oct 14, 2013 at 9:08 AM, Dehao Chen wrote:
> This patch forces to use profile info to check if an edge is hot when
> profile is available.
>
> Bootstrapped and passed regression tests.
>
> OK for trun
This patch forces to use profile info to check if an edge is hot when
profile is available.
Bootstrapped and passed regression tests.
OK for trunk?
Thanks,
Dehao
gcc/ChangeLog:
2013-10-14 Dehao Chen
* predict.c(cgraph_maybe_hot_edge_p): Decide edge's hotness from profile.
Index: gcc/predict
42 matches
Mail list logo
