This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] decide edge's hotness when there is profile info
- From: Teresa Johnson <tejohnson at google dot com>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: Dehao Chen <dehao at google dot com>, Xinliang David Li <davidxl at google dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Uros Bizjak <ubizjak at gmail dot com>
- Date: Tue, 12 Nov 2013 14:06:47 -0800
- Subject: Re: [PATCH] decide edge's hotness when there is profile info
- Authentication-results: sourceware.org; auth=none
- References: <CAAe5K+WZ2=YavTXf3yzdRHOmO9rEhvUM6xpDUKiRhkGhbX6JBQ at mail dot gmail dot com> <CAAe5K+UOn4wxvwsGhy_EjiFFQMDB-emRbpNJkY5bBf6QgRJo4w at mail dot gmail dot com> <20131111152309 dot GC4119 at atrey dot karlin dot mff dot cuni dot cz> <CAAe5K+UgOsGOA7AfRRPVyj3nb-fYGu4-gFkjWBY1fcu1PWsR-w at mail dot gmail dot com> <20131111162226 dot GD4119 at atrey dot karlin dot mff dot cuni dot cz> <CAAe5K+USHR0AdRAYEVFwGfXJjsvWmvB_GVFT90MR+s7NnN4Y4w at mail dot gmail dot com> <20131111171307 dot GA22469 at atrey dot karlin dot mff dot cuni dot cz> <CAAe5K+Xuk=u_d+q+mPwyjvW6CVoOZmECYGF161pNi7j+vgpRbg at mail dot gmail dot com> <CAAe5K+XLqo8cUjS=GA78ezT7BQMk0YqxXhTpkARaodKFr79_1A at mail dot gmail dot com> <CAAe5K+VnYRtYgQFxch2gNKTZCf-FKHTCXhegaLSfhad4-R8mew at mail dot gmail dot com> <20131112213306 dot GA14050 at kam dot mff dot cuni dot cz>
On Tue, Nov 12, 2013 at 1:33 PM, Jan Hubicka <hubicka@ucw.cz> 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 error handling routine that invokes _exit. Looking at the
>> ipa-profile dump, I can see that all the counts read in for
>> pex_child_error have the value 0. But there is a non-zero callsite,
>> that not surprisingly complains of a profile insanity in the bb's
>> outgoing edge weights, since pex_child_error never returns:
>>
>> ;; basic block 38, loop depth 1, count 192, freq 5000
>> ;; Invalid sum of outgoing counts 0, should be 192
>> ...
>> pex_child_error.isra.1D.5005 (_92, executable_40(D),
>> [/usr/local/google/home/tejohnson/gcc_trunk_9/libiberty/pex-unix.c :
>> 677] "execv", _91);
>> ;; succ: 3 [100.0%] (ABNORMAL,DFS_BACK,IRREDUCIBLE_LOOP,EXECUTABLE)
>>
>> Not sure why the counts were all 0 for this routine though, I wouldn't
>> think the early exit should prevent us from updating the counts. But
>> IMO the best thing to do here is to issue a warning, since I don't
>> want more issues like this to cause compile errors when we handled
>> them fine before.
>>
>> Let me know if the patch below is ok.
>
> OK, so _exit actually makes us to miss streaming of the path leading to the
> error message? Handling of vfork is somewhat broken, as I noticed with Martin
> Liska. One problem is that gcov_exit is not clearing the counts. With vfork
> being used in addition to execvs we stream out the data but the counts stays in
> the oriignal process memory and then are streamed again. If execve fails and
> leads to _exit I think we can get the miscompare you see.
>
> Does calling gcov_clear within gcov_exit help? (It is what I have in our tree)
I thought this was already handled by the __gcov_execv wrapper around
execv which invokes __gcov_flush that in turns does a gcov_exit
followed by gcov_clear?
I think the issue is that we register gcov_exit with atexit(), but
_exit does not execute any atexit functions by definition. So that
would explain why the counters from pex_child_error didn't get dumped.
The caller bb invokes execv before invoking pex_child_error:
execv (executable, to_ptr32 (argv));
pex_child_error (obj, executable, "execv", errno);
So the counters of the caller bb are dumped (hence the caller bb has
non-zero counts) and cleared, and the pex_child_error does not dump
its counters since it uses _exit instead of exit and therefore doesn't
invoke gcov_exit atexit.
If that is what is going on, then I don't see how adding a call to
gcov_clear to gcov_exit would help. Dealing with situations like this
is why I think it is better to convert this to a warning.
Teresa
>
> Honza
--
Teresa Johnson | Software Engineer | tejohnson@google.com | 408-460-2413