Loop-iv.c ICEs on subregs

[Maxim Kuvyrkov <maxim at codesourcery dot com>]

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