[Bug target/39423] [4.6/4.7/4.8 Regression] [SH] performance regression: lost mov @(disp,Rn)

["olegendo at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39423

--- Comment #29 from Oleg Endo <olegendo at gcc dot gnu.org> 2012-08-10 13:26:52 UTC ---
(In reply to comment #28)
> 
> This ICE does happen on trunk (rev190294). I have a testcase for it that I'm
> reducing. There was a second ICE introduced by 190259 as well. 
> 
> /home/ryan/ice2.i:9312:1: error: unrecognizable insn:
>  }
>  ^
> (insn 780 647 781 28 (set (reg:SI 530)
>         (ashift:SI (reg:SI 147 t)
>             (const_int 1 [0x1]))) /home/ryan/ice2.i:9270 -1
>      (nil))
> /home/ryan/ice2.i:9312:1: internal compiler error: in extract_insn, at
> recog.c:2125
> 
> Should I attach the testcases to this PR or open a new PR?

This left shift ICE looks like a problem I introduced with changes in PR 54089.
Please post the testcase for this in PR 54089.

BTW, I've confirmed my guess in comment #27 that the following function

int test00 (int tab[], int i)
{
  return tab[i * 8192 + 4];
}

will currently ICE when compiled for -m2 and will produce potentially wrong
code around the T_REG for -m2a and -m3.  Checking it out...