[Bug target/48830] [4.4/4.5/4.6/4.7 Regression] unrecognized insn: storing invalid upper fp reg in SImode to stack

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson <hp at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.4/4.6 Regression]        |[4.4/4.5/4.6/4.7
                   |unrecognized insn storing   |Regression] unrecognized
                   |fp (simd) reg in SImode to  |insn: storing invalid upper
                   |stack                       |fp reg in SImode to stack

--- Comment #3 from Hans-Peter Nilsson <hp at gcc dot gnu.org> 2011-05-01 00:31:15 UTC ---
I had a look.  The code needs to split %f34 and get the two SImode quantities
that happen to be in %f34.  This should be done by a stack intermediate, but
when doing that, reloads trips and falls.

The root problem seems to be that the SPARC port allows a change from DImode to
SImode for regno 66 (%f34) (by CANNOT_CHANGE_MODE_CLASS) even though there's no
%f35 and no way to move around such a small quantity, also specified through
HARD_REGNO_MODE_OK(either of 66 and 67, SImode) being 0.  So, reload happily
wraps the reg in a subreg and calls emit_move_insn.

It seems wrong for the sparc CANNOT_CHANGE_MODE_CLASS to not refuse this
change, but also wrong for subreg_get_info to not consult HARD_REGNO_MODE_OK
when setting info.representable_p (as "%f35" is flagged as representable, which
it isn't according to the related field comment in rtl.h).  There's a kludge
involving the latter, that implies that such a non-representable register is
expected to be flagged as representable (ugh!), see last "return -1" in
simplify_subreg_regno.