https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106495
--- Comment #9 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #7)
> So in this case we have
>
> (gdb) p *path->m_vec->m_vecdata[0]
> $106 = {e = <edge 0xf4819a40 (5 -> 7)>, type = EDGE_COPY_SRC_BLOCK}
> (gdb) p *path->m_vec->m_vecdata[1]
> $107 = {e = <edge 0xf48199a0 (7 -> 9)>, type = EDGE_COPY_SRC_BLOCK}
> (gdb) p *path->m_vec->m_vecdata[2]
> $108 = {e = <edge 0xf48197e0 (9 -> 10)>, type = EDGE_NO_COPY_SRC_BLOCK}
>
> and the last edge (9 -> 10) is known to be never executed:
>
> <bb 9> [local count: 435262723]:
> _3 = MEM <struct vec> [(struct basic_block_def * const &)_21].m_vecdata[_2];
> _4 = iftmp.22_23 + 4294967295;
> if (_4 >= _20)
> goto <bb 10>; [0.00%]
>
> we've isolated a quite "unlikely" combo here. We could go for generalizing
> the earlier patch, disqualifying the path if any of the edges involved.
>
> Note that profitable_path_p only gets to see 5->7->9, strangely not the
> final ->10? It look like only maybe_register_path () via find_taken_edge
> will ask profitable_path_p _again_ (but with taken_edge now set)!?
profitable_path_p gets called during path discovery (find_paths_to_names), so
we don't have complete info. The idea is that if a path so far is
unprofitable, no sense looking further in that particular direction. In
reality Jeff and I ran into a testcase where a partial path was not profitable,
but a path with some extra blocks was. There's a PR somewhere for it, but it
happened so infrequent, that this heuristic was good enough.
>
> So the "cheapest" way to tackle this particular case is look at taken_edge
> in profitable_path_p.
I would've prefered putting everything in your previous patch, since it would
be shared between both threaders, though I suppose the forward threader is
slowly dying ;-).
