https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67755
Jeffrey A. Law <law at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |law at redhat dot com
--- Comment #7 from Jeffrey A. Law <law at redhat dot com> ---
Indeed this is a problem in the corrections done to account for multiple jump
thread paths going through the same joiner, but reaching different ultimate
destinations.
To avoid profiling "insanities", the code tries to ensure a minimum amount of
profile count goes to the ultimate destination when we thread through a joiner.
That minimum is meant to account for the possibility that a different jump
threading path may totally eliminate counts going to that destination.
That seems to essentially be papering over problems elsewhere, particularly in
update_profile. It's not clear yet if update_profile is fixable though. At
one time I wondered if we even really needed the corrections, but I certainly
saw more "profiling insanities" when I disabled the corrective step.
The patch I'm testing for gcc6 limits application of the correction to cases
where there are actually multiple jump threading paths through the same join
block that reach different destinations. That fixes the bogus probabilities in
the testcase and generally seems to help sort out clearly bogus probabilities
in the larger codes I looked at. The most common scenario is we'd have two
outgoing edges, one with 100% probability, the other with 0% probability (which
you'll note is roughly the same situation as Pat describes). After the patch,
the probabilities appear to be much more normal.
