Created attachment 28358 [details] spills.txt: Hundreds of Spill Fails The testsuit throws hundreds of spill fails when running against the avr cross compiler. The testsuite used to produce about ~5 spill fails with avr-gcc. The strange with these spill fails is that they report register class RO_REG which contains just one fixed register. ./gcc/testsuite/gcc.c-torture/compile/20010426-1.c:19:1: error: unable to find a register to spill in class 'R0_REG' ./gcc/testsuite/gcc.c-torture/compile/20040121-1.c:41:1: error: unable to find a register to spill in class 'R0_REG' ... For a complete list see attachment. == configure == SVN trunk r192090 from today (2012-10-04) $ ../../gcc.gnu.org/trunk/configure --target=avr --prefix=/local/gnu/install/gcc-4.8 --disable-nls --with-dwarf2 --enable-target-optspace=yes --enable-languages=c,c++
Setting to NEW. There is enough evidence from the test cases in the test suite. Moreover, I am getting this ICE with real-world code so this is not just a purely academic problem.
rguenth at gcc dot gnu.org wrote: > spill in class 'R0_REG' Spilling is a bug in the register allocator, or am I missing something. Besides that, I am getting this mail because I am CCed to PR54814 but your comment spill in class 'R0_REG' is missing in PR54814 so nobody can really follow what is going on for what reason. Johann > > Date: Fri, 07 Dec 2012 11:46:42 +0000 > > X-Bugzilla-Reason: Reporter > > X-Bugzilla-Type: changed > > X-Bugzilla-Watch-Reason: None > > X-Bugzilla-Product: gcc > > X-Bugzilla-Component: other > > X-Bugzilla-Keywords: ice-on-valid-code, ra > > X-Bugzilla-Severity: normal > > X-Bugzilla-Who: rguenth at gcc dot gnu.org > > X-Bugzilla-Status: NEW > > X-Bugzilla-Priority: P4 > > X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org > > X-Bugzilla-Target-Milestone: 4.8.0 > > X-Bugzilla-Changed-Fields: Priority > > Message-ID: <bug-54814-20453-4HTXOBm3vX@http.gcc.gnu.org/bugzilla/> > > In-Reply-To: <bug-54814-20453@http.gcc.gnu.org/bugzilla/> > > References: <bug-54814-20453@http.gcc.gnu.org/bugzilla/> > > X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ > > Auto-Submitted: auto-generated > > Content-Type: text/plain; charset="UTF-8" > > MIME-Version: 1.0 > > > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54814 > > > > Richard Biener <rguenth at gcc dot gnu.org> changed: > > > > What |Removed |Added > > ---------------------------------------------------------------------------- > > Priority|P3 |P4 > > >
Richard, would you explain why this is a target issue? R0 is a fixed register, it should not be used for spilling or be allocated by IRA.
(In reply to comment #3) > R0 is a fixed register, it should not be used for spilling or be allocated by > IRA. But apparently RA believes it has to, to satisfy some constraints. Difficult to say exactly, without a little more context. Cross-compiler from what to what? What else does spill_failure print? spills.txt only shows the ICEs, but spill_failure prints a lot of information about what failed -- that's actually useful information for folks willing to help here but not willing to build a cross-compiler for it ;-)
For 20010426-1.c at -O1: (gdb) p debug_rtx(insn) (insn 168 167 169 10 (set (reg:QI 3 r3 [orig:118 a_I_m_lsm.5+1 ] [118]) (subreg:QI (reg/f:HI 105 [ a_I_m_lsm.5 ]) 1)) 20010426-1.c:12 70 {movqi_insn} (nil)) $1 = void (gdb) p debug_reload_to_stream(stderr) Reload 0: reload_in (HI) = (symbol_ref/f:HI ("*.LC0") [flags 0x2] <var_decl 0x7ffff63f0720 *.LC0>) R0_REG, RELOAD_FOR_INPUT (opnum = 1) reload_in_reg: (symbol_ref/f:HI ("*.LC0") [flags 0x2] <var_decl 0x7ffff63f0720 *.LC0>) Reload 1: reload_in (QI) = (subreg:QI (symbol_ref/f:HI ("*.LC0") [flags 0x2] <var_decl 0x7ffff63f0720 *.LC0>) 1) GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1), can't combine reload_in_reg: (subreg:QI (reg/f:HI 105 [ a_I_m_lsm.5 ]) 1) reload_reg_rtx: (reg:QI 3 r3 [orig:118 a_I_m_lsm.5+1 ] [118]) $2 = void For 930120-1.c at -O2: Breakpoint 1, spill_failure (insn=0x7ffff6444990, rclass=R0_REG) at ../../trunk/gcc/reload1.c:2108 2108 if (asm_noperands (PATTERN (insn)) >= 0) (gdb) p debug_rtx(insn) (insn 173 170 176 28 (set (mem:QI (post_dec:HI (reg/f:HI 32 __SP_L__)) [0 S1 A8]) (subreg:QI (reg/f:HI 487) 1)) 930120-1.c:67 1 {pushqi1} (expr_list:REG_ARGS_SIZE (const_int 3 [0x3]) (nil))) $1 = void (gdb) p debug_reload_to_stream(stderr) Reload 0: reload_in (HI) = (symbol_ref/f:HI ("*.LC2") [flags 0x2] <var_decl 0x7ffff6420850 *.LC2>) R0_REG, RELOAD_FOR_INPUT (opnum = 0) reload_in_reg: (symbol_ref/f:HI ("*.LC2") [flags 0x2] <var_decl 0x7ffff6420850 *.LC2>) Reload 1: reload_in (QI) = (subreg:QI (symbol_ref/f:HI ("*.LC2") [flags 0x2] <var_decl 0x7ffff6420850 *.LC2>) 1) GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 0), can't combine reload_in_reg: (subreg:QI (reg/f:HI 487) 1) $2 = void (gdb) In both cases reload is trying to reload a symbol_ref to an R0_REG class.
Difficult to bisect, there are no test results posted on gcc-testresults...
Many thanks for your help! Mike Stein stopped posting test results quite some time ago. Dunno why, he does not respond to email. avr.h defines R0_REG as register class with 1 fixed register, r0. This regclass is subset of NO_LD_REGS and GENERAL_REGS, which is odd. R0_REG does not make much sense to me, thus remove it from NO_LD_REGS and GENERAL_REGS or delete that regclass and constraint "t" completely. I'll try next week and report back.
Trying to bisect down to the revision where this problem appeared: Fail: 193053 (1 Nov 2012) Fail: 191882 (1 Oct 2012) Pass: 188094 (1 Jun 2012) Pass: 190028 (1 Aug 2012) Fail: 190845 (1 Sep 2012) Fail: 190426 (16 Aug 2012) -- does not build, double_int issues Fail: 190521 (20 Aug 2012) Pass: 190219 (8 Aug 2012) Fail: 190324 (12 Aug 2012) Fail: 190277 (10 Aug 2012) Pass: 190246 (9 Aug 2012) Fail: 190257 (9 Aug 2012) Fail: 190252 (9 Aug 2012) Pass: 190251 (9 Aug 2012) Thus, caused by: http://gcc.gnu.org/ml/gcc-cvs/2012-08/msg00229.html
Created attachment 28900 [details] Candidate patch Try this.
(In reply to comment #9) > Created attachment 28900 [details] > Candidate patch > > Try this. It works. There are no more "spill in class 'R0_REG'" ICEs wozj your patch (atop trunk 194354)
(In reply to comment #9) > Created attachment 28900 [details] > Candidate patch > > Try this. Bernd, do you intend to apply this, or should I post it for review?
Created attachment 28990 [details] Better patch Sorry for doing this, but here's a slightly improved version of the patch. Does this also fix the issue? This one was bootstrapped and tested on x86_64-linux, so it could go in if it works; not sure I want to do that before I stop reading email for the next two weeks though.
(In reply to comment #12) > Created attachment 28990 [details] > Better patch > > Sorry for doing this, but here's a slightly improved version of the patch. Does > this also fix the issue? Yes, at least I don't see "spill in class 'R0_REG'" in the testsuite with attachment 28990 [details].
Attachment 28990 [details] is pending review at http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01255.html with the following ChangeLog: PR other/54814 * reload.c (find_valid_class_1): Use in_hard_reg_set_p instead of TEST_HARD_REG_BIT.
Author: gjl Date: Mon Jan 28 20:03:26 2013 New Revision: 195515 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195515 Log: PR other/54814 * reload.c (find_valid_class_1): Use in_hard_reg_set_p instead of TEST_HARD_REG_BIT. Modified: trunk/gcc/ChangeLog trunk/gcc/reload.c
Fixed for the milestone.