https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98464
Kewen Lin <linkw at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
CC| |rguenth at gcc dot gnu.org
--- Comment #3 from Kewen Lin <linkw at gcc dot gnu.org> ---
My commit exposed one issue in FRE. The reason why the ICE occurs is that one
SSA_NAME used in loop's nb_iterations is actually in free list.
(unsigned long) _54 - (unsigned long) v$ptr__25
arg:0 <ssa_name 0x7ffff5549558 type <error_mark 0x7ffff54a1188>
nothrow
def_stmt
version:54 in-free-list>>
I noticed that FRE already has some codes to handle loop's nb_iterations, but
there are some inconsistence which cause FRE unable to replace the one in
loop's nb_iterations but later replace all uses of _54.
When FRE is processing BB 19, it's able to replace _54 with _53 like:
<bb 19> [local count: 789698041]:
...
if (_26 != v$D4172$_M_impl$D4082$_M_finish$ptr__54)
goto <bb 28>; [89.00%]
=>
<bb 19> [local count: 789698041]:
...
if (_26 != __new_finish$ptr__53)
goto <bb 28>; [89.00%]
since it calls eliminate_stmt which works with def_bb instead of current bb:
sprime = eliminate_avail (gimple_bb (SSA_NAME_DEF_STMT (use)), use)
while rpo_vn_valueize only works with vn_context_bb.
For this particular case, _54's def_bb is BB 13, _53's def_bb is BB 11, it's ok
for dominated_by_p_w_unex check. While vn_context_bb is BB 19,
dominated_by_p_w_unex check returns false for it.
