Zdenek,
I'm investigating an ICE in loop-iv.c:get_biv_step(). I hope you can shed some
light on what the correct fix would be.
The ICE happens when processing:
==
(insn 111 (set (reg:SI 304)
(plus (subreg:SI (reg:DI 251) 4)
(const_int 1))))
(insn 177 (set (subreg:SI (reg:DI 251))
(reg:SI 304)))
==
The code like the above does not occur on current mainline early enough for
loop-iv.c to catch it. The subregs above are produced by Tom's (CC'ed)
extension elimination pass (scheduled before fwprop1) which is not in mainline
yet [*].
The failure is due to assert in loop-iv.c:get_biv_step():
==
gcc_assert ((*inner_mode == *outer_mode) != (*extend != UNKNOWN));
==
i.e., inner and outer modes can differ iff there's an extend in the chain.
Get_biv_step_1() starts with insn 177, then gets to insn 111, then loops back
to insn 177 at which point it stops and returns GRD_MAYBE_BIV and sets:
* outer_mode == DImode == natural mode of (reg A);
* inner_mode == SImode == mode of (subreg (reg A)), set in get_biv_step_1:
==
if (GET_CODE (next) == SUBREG)
{
enum machine_mode amode = GET_MODE (next);
if (GET_MODE_SIZE (amode) > GET_MODE_SIZE (*inner_mode))
return false;
*inner_mode = amode;
*inner_step = simplify_gen_binary (PLUS, outer_mode,
*inner_step, *outer_step);
*outer_step = const0_rtx;
*extend = UNKNOWN;
}
==
* extend == UNKNOWN as there are no extensions in the chain.
It seems to me that computations of outer_mode and extend are correct, I'm not
sure about inner_mode.
Zdenek, what do you think is the right way to handle the above case in loop
analysis?
[*] http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01529.html
Thanks,
--
Maxim Kuvyrkov
CodeSourcery
+1-650-331-3385 x724
