[Bug target/48830] [4.4/4.5/4.6/4.7 Regression] unrecognized insn: storing invalid upper fp reg in SImode to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48830 --- Comment #11 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-05-29 20:01:45 UTC --- Author: ebotcazou Date: Sun May 29 20:01:41 2011 New Revision: 174414 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=174414 Log: PR target/48830 * rtlanal.c (simplify_subreg_regno): Adjust comment. Modified: trunk/gcc/ChangeLog trunk/gcc/rtlanal.c
[Bug target/48830] [4.4/4.5/4.6/4.7 Regression] unrecognized insn: storing invalid upper fp reg in SImode to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48830 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||ebotcazou at gcc dot ||gnu.org --- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-05-01 08:46:28 UTC --- 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. Right, CANNOT_CHANGE_MODE_CLASS doesn't need to prohibit mode changes already forbidden by HARD_REGNO_MODE_OK. I'm a bit reluctant to tweak the macro on the release branches because this is a sensitive one. 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. Indeed, looks like SPARC gets bitten by its own laziness here. I think that we should first try to get rid of the kludge on the mainline. I'll investigate on my side.
[Bug target/48830] [4.4/4.5/4.6/4.7 Regression] unrecognized insn: storing invalid upper fp reg in SImode to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48830 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW --- Comment #8 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-05-01 11:03:45 UTC --- (In reply to comment #7) 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) I'm a bit reluctant to tweak the macro on the release branches because this is a sensitive one. A quick vetting of uses will hopefully convince you like me: when CLASS is EXTRA_FP_REGS, for at least 4.4 and trunk all uses seem to be from testing an upper floating-point register number, for which TO has no reason to be SImode. Being a port-local change, this seems as safe as it can be. (Famous last words.) BTW incidentally-related: maybe a good time to introduce a register class that is actually the EXTRA_FP_REGS (the upper ones), with its current contents renamed to ALL_FP_REGS. See misnomer in the sparc.h enum reg_class comment. I'll investigate on my side. Very much appreciated. Feel free to take the bug; I'm unassigning myself as I can't commit to testing the patches (at least) the next few days.
[Bug target/48830] [4.4/4.5/4.6/4.7 Regression] unrecognized insn: storing invalid upper fp reg in SImode to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48830 --- Comment #9 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-05-01 11:26:02 UTC --- It's probably a good idea to test patches to subreg_get_info on an e500 target such as powerpc-eabispe. I don't *think* e500 is doing anything that would be affected by the proposed patch, but what it does with subregs is fiddly enough (and is the reason for some of the code in subreg_get_info) that any changes to subreg_get_info could easily show up problems there.
[Bug target/48830] [4.4/4.5/4.6/4.7 Regression] unrecognized insn: storing invalid upper fp reg in SImode to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48830 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |ebotcazou at gcc dot |gnu.org |gnu.org Target Milestone|--- |4.6.1 --- Comment #10 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-05-01 12:42:36 UTC --- A quick vetting of uses will hopefully convince you like me: when CLASS is EXTRA_FP_REGS, for at least 4.4 and trunk all uses seem to be from testing an upper floating-point register number, for which TO has no reason to be SImode. That's what I'm not convinced of. In 64-bit mode, the 'e' constraint is mapped to EXTRA_FP_REGS, not FP_REGS, so this class cannot be used to distinguish lower from upper regs in a bunch of FP insns. I don't think the bug is serious enough as to warrant any risk on old (4.4/4.5) release branches; a simple workaround is to replace -O2 with -O on the command line. But I agree that fixing it in 4.6.1 would be desirable. BTW incidentally-related: maybe a good time to introduce a register class that is actually the EXTRA_FP_REGS (the upper ones), with its current contents renamed to ALL_FP_REGS. See misnomer in the sparc.h enum reg_class comment. This would be sort of an earthquake in the back-end though. Very much appreciated. Feel free to take the bug; I'm unassigning myself as I can't commit to testing the patches (at least) the next few days. OK, I'm taking it.
[Bug target/48830] [4.4/4.5/4.6/4.7 Regression] unrecognized insn: storing invalid upper fp reg in SImode to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48830 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |hp at gcc dot gnu.org |gnu.org | --- Comment #4 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-05-01 00:34:15 UTC --- Created attachment 24155 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24155 Tentative patch fixing the sparc CANNOT_CHANGE_MODE_CLASS, untested.
[Bug target/48830] [4.4/4.5/4.6/4.7 Regression] unrecognized insn: storing invalid upper fp reg in SImode to stack
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.
[Bug target/48830] [4.4/4.5/4.6/4.7 Regression] unrecognized insn: storing invalid upper fp reg in SImode to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48830 --- Comment #5 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-05-01 01:50:46 UTC --- Created attachment 24156 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24156 Tentative patch fixing subreg_get_info, untested. This likely has fallout for sparc 32-bit, as it removes the kludge mentioned above; I haven't even had a look whether that's still needed.
[Bug target/48830] [4.4/4.5/4.6/4.7 Regression] unrecognized insn: storing invalid upper fp reg in SImode to stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48830 --- Comment #6 from Hans-Peter Nilsson hp at gcc dot gnu.org 2011-05-01 01:52:16 UTC --- Either patch fixes the test-case. Both should eventually be applied to trunk, but perhaps just the sparc one to branches.
