https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106495
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aldyh at gcc dot gnu.org
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
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)!?
So the "cheapest" way to tackle this particular case is look at taken_edge
in profitable_path_p.
