[PATCH] decide edge's hotness when there is profile info

[Jan Hubicka]

> 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.

Hmm, I see, the problem here is that execv gets BB splitted (and profile is correct)
but before we get into ipa_profile the BBs get re-merged and we incorrectly put
count of 1 to pex_child_error.

I suppose this will always happen when you have function terminating program
(execve) before other function call.  Perhaps we can warn only when the difference in counts
is greater than number of train runs?  

Honza