This is the mail archive of the
mailing list for the GCC project.
Re: [patch] Prevent -fprofile-arcs and -fbranch-probabilities rtl from diverging
- From: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
- To: Nathan Sidwell <nathan at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org, jh at suse dot cz
- Date: Mon, 15 Mar 2004 15:08:32 +0100
- Subject: Re: [patch] Prevent -fprofile-arcs and -fbranch-probabilities rtl from diverging
- References: <20040314162423.GA28990@atrey.karlin.mff.cuni.cz> <4055B57A.firstname.lastname@example.org>
> >in code that calls fork or exec functions, the rtl generated for
> >-fprofile-arcs slightly differ from the one generated for
> >-fbranch-probabilities, since in the former case we insert calls to
> >gcov_flush before fork/exec. This may cause the code diverge (as indeed
> >happened to me during value profiling enhancement testing) enough so
> >that the counters issued with -fprofile-arcs do not those that
> >-fbranch-probabilities expects.
> >This patch fixes it (or better said, moves it closer to the correct
> >state) by replacing the fork/exec call by a call to a library function
> >that calls gcov_flush and the original function, in the program compiled
> >with -fprofile-arcs. This makes the code more similar, thus preventing
> >the divergence.
> Hmm, it's not immediately obvious to me as to why inserting the
> gcov_flush call causes the bb graph to change.
because the optimizations before the profiling now work on different
code, and thus behave slightly differently; I did not hunt the change
down to one particular optimization (mostly because it would be a clear
waste of the time -- there is nothing wrong with the optimization and
avoiding this behavior is not a correct way of fixing the problem).
> >Of course this will become unnecesary once the profiling is done on
> >trees, since there it won't be a problem to insert the gcov_flush
> >calls after the profile feedback stage.
> This patch is large and it is a stopgap measure within
> the current development series. We run the significant risk of it
> remaining in the compiler after ssa obsoletes it.
Does not seem quite probable to me (just noting it to my todo list
should prevent this :-). I posted this patch because without it
my second patch (the speculative prefetching) fails to compile