Hi!
Apparently, for iv->extend == IV_UNKNOWN_EXTEND if iv->mode !=
iv->extend_mode get_iv_value returns a value in iv->mode mode, while
otherwise in iv->extend_mode. This makes some sense, because with
IV_UNKNOWN_EXTEND the upper bits are unknown, so there is nothing reasonable
to return in the extended mode. But e.g. iv_subreg when it calls assumed
unconditionally the value would be in iv->extend_mode (the reason for the
ICE on the attached testcase). Furthermore, for iv_extend, IMHO if
iv->extend isn't IV_UNKNOWN_EXTEND, but is different from the new extend,
the middle bits might be incorrect. And, lastly, I think may_unswitch_on
assumes the returned values will be in the expected mode (iv->mode), but
they can be wider and that can result in invalid RTL (say comparing of
SImode with DImode rtl), or wrong code.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk and for 4.8 later?
2013-11-05 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/58997
* loop-iv.c (iv_subreg): For IV_UNKNOWN_EXTEND, expect
get_iv_value to be in iv->mode rather than iv->extend_mode.
(iv_extend): Likewise. Otherwise, if iv->extend != extend,
use lowpart_subreg on get_iv_value before calling simplify_gen_unary.
* loop-unswitch.c (may_unswitch_on): Make sure op[i] is in the right
mode.
* gcc.c-torture/compile/pr58997.c: New test.