[Bug bootstrap/63432] [5 Regression] profiledbootstrap failure with bootstrap-lto

["law at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432

--- Comment #19 from Jeffrey A. Law <law at redhat dot com> ---
On 10/04/14 09:34, Teresa Johnson wrote:
>
> Looking at the code, I think it attempts to check for this case and
> prevent it but that code does not work in this case because of the
> order the paths are identified and subsequently iterated in the paths
> vec. In mark_threaded_blocks it looks at paths with joiners and if
> there are any edges along the path already part of another path it
> will skip that path. But in this case, we registered the paths in this
> order:
>
>    Registering jump thread: (119, 150) incoming edge;  (150, 13)
> joiner;  (13, 15) normal;
> ...
>    Registering jump thread: (150, 13) incoming edge;  (13, 15) joiner;
> (15, 17) normal;
>
> For the first path, the path is attached to incoming edge 119->150. So
> when we walk edges in the 2nd path we don't see the first path. If we
> looked at the paths in the reverse order we would have seen the path
> attached to incoming edge 150->13 and skipped the 119->150 path. Note
> that we end up doing the actual threading in the reverse order - first
> we do the threading through 13 (the second path), then later the
> threading through 150 (the first path), leading to the issue I am
> seeing.
>
> Jeff, what is intended here - should we not be threading both of these paths?
The code in mark_threaded_jumps looks for cases where there is a jump 
threading path with a joiner block is subsumed by a jump threading path 
without a joiner block and it will suppress the jump threading path with 
the joiner.  We had more suppressed paths in the past, but they mostly 
got ripped out as the implementation solidified.

In the case shown above, we have two paths with joiner blocks so the 
suppression code in mark_threaded_blocks does not fire and we attempt to 
realize both jump threading paths.

 From a correctness standpoint the code should handle this case; 
however, there may be strong reasons to suppress one path or the other 
from a code bloat and/or performance standpoint.

I typically have to draw out the CFG and the intermediate steps to gain 
clarity into the desired result and there's not enough info here to do 
that.   My gut tells me suppression of one jump thread path is 
desirable, we aren't going to have anything good to guide which path to 
suppress, the vast majority of the time it won't matter which path is 
suppressed.  So I'm comfortable with suppressing either path.

jeff