[Bug target/53250] [4.8 Regression] [SH] ICE: in change_address_1, at emit-rtl.c:2018

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

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

--- Comment #2 from Oleg Endo <olegendo at gcc dot gnu.org> 2012-05-06 18:04:27 UTC ---
Created attachment 27326
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27326
Proposed patch

(In reply to comment #0)
> On sh4-unknown-linux-gnu, there are many new failures after revision
> 187015.  The typical example is gcc.c-torture/compile/20071102-1.c
> which fails with
> 
> internal compiler error: in change_address_1, at emit-rtl.c:2018
> 
> It seems that rtls like
> 
> (subreg:SF (reg:DI ...) 4)
> (subreg:SF (reg:V2SF ...) 4)
> 
> cause this error when regs are on stack.  If my memory is correct,
> the similar issue has popped up on oleg's work for QI/HImode addressing
> with displacement.

Do you mean this wallpapering below?

sh.c (sh_cannot_change_mode_class) ...

  /* This effectively disallows using GENERAL_REGS for SFmode vector subregs.
     This can be problematic when SFmode vector subregs need to be accessed
     on the stack with displacement addressing, as it happens with -O0.
     Thus we disallow the mode change for -O0.  */
  if (to == SFmode && VECTOR_MODE_P (from) && GET_MODE_INNER (from) == SFmode)
    return optimize ? (reg_classes_intersect_p (GENERAL_REGS, rclass)) : false;

I think this one is a different issue...

> The above rtls are not illegal but problematic
> when regs are on stack because SH has no load/store instructions
> for FP registers and memory with displacement.  Before lowering
> subregs change in revision 187015, these subregs were decomposed
> into subregs with zero byte count.
> The trails of PR53716 say that the appropriate target-wise cost
> computation is needed, though I can't find the way to enable
> lowering the above subregs with adjusting SH's rtx cost computations.

I had a look at what's going on there.
The lower-subreg pass decides whether to do the splitting or not based on the
reg move costs of certain modes.  These costs are initially collected by
querying the rtx cost for patterns like "(set (reg:DI 154
virtual-incoming-args)".
A simple stack trace ...

lower_subreg (compute_costs)
  rtx = (set (reg:DI 154 virtual-incoming-args)

  -> insn_rtx_cost

    -> set_src_cost

      -> rtx_cost (x, SET, 1, speed_p)
    switch (code)
    {
      case REG:
        return 0;
    }

The 'rtx_cost' function always returns 0 because 'code' is 'REG', so it never
reaches sh_rtx_costs.  I wonder how this could have worked for other targets at
all.

The attached patch seems to fix the issue (at least newlib compiles for me
now).  
However, I'm completely unaware of any consequences of the rtlanal.c hunk. 
Maybe somebody else should have a look at it.