Fix PR target/17245

Eric Botcazou ebotcazou@libertysurf.fr
Fri Oct 8 14:26:00 GMT 2004


This is an ICE at -O -mcpu=v9 on SPARC 32-bit, a regression present on the 
3.4 branch.  The reload pass generates an invalid insn:

ultrasp11.c: In function `f':
ultrasp11.c:25: error: insn does not satisfy its constraints:
(insn 169 9 11 0 (set (reg:TF 10 %o2)
        (mem/u/f:TF (lo_sum:SI (reg/f:SI 1 %g1 [111])
                (symbol_ref/u:SI ("*.LLC0") [flags 0x2])) [0 S16 A64])) 98 
{*movtf_insn_sp32} (nil)
    (nil))
ultrasp11.c:25: internal compiler error: in reload_cse_simplify_operands, at 
postreload.c:391

It is invalid because the address is not offsettable (with the Sun assembler)
and the pattern wants it to be offsettable for subsequent splitting.

This insn is emitted as part of reload #1 for:

(insn 11 9 13 0 (set (reg/v:TF 109 [ W ])
        (mem/u/f:TF (lo_sum:SI (reg/f:SI 111)
                (symbol_ref/u:SI ("*.LLC0") [flags 0x2])) [0 S16 A64])) 98 
{*movtf_insn_sp32} (insn_list 9 (nil))
    (expr_list:REG_DEAD (reg/f:SI 111)
        (nil)))

(reg/v:TF 109 [ W ]) doesn't get a hard-reg so reload needs to fix up a move 
between two MEMs with TFmode.  %o2 is selected as the reload register and 
the insn loading the register is emitted without further ado since the 
address is generically valid.


This appears to be a limitation of the reload pass, as the SPARC back-end 
already has provisions to dealt with it in a very similar case, the REG+REG 
address form which is not offsettable either:

	  /* We prohibit REG + REG for TFmode when there are no instructions
	     which accept REG+REG instructions.  We do this because REG+REG
 	     is not an offsetable address.  If we get the situation in reload
 	     where source and destination of a movtf pattern are both MEMs with
 	     REG+REG address, then only one of them gets converted to an
 	     offsetable address.  */

So I think it is reasonable to prohibit LO_SUM for TFmode too, when LO_SUM is 
not offsettable.  Note that the testcase doesn't ICE with -mcpu=v8 because 
LO_SUM is already rejected in this case, and actually doubly rejected since 
input_operand and legitimate_address_p contain redundant code.

Bootstrapped/regtested on sparc64-sun-solaris2.9 and sparc-sun-solaris2.8, 
applied to mainline and 3.4 branch.


2004-10-08  Eric Botcazou  <ebotcazou@libertysurf.fr>

	PR target/17245
	* config/sparc/sparc.c (input_operand): Remove redundant code
	for handling LO_SUM.
	(legitimate_address_p) <REG+REG>: Do not recheck TARGET_V9.
	<LO_SUM>: If LO_SUM is offsettable, accept it for TFmode on V9.
	Otherwise only accept it for TFmode if quad move insns are available.


2004-10-08  Christian Ehrhardt  <ehrhardt@mathematik.uni-ulm.de>

	* gcc.dg/ultrasp11.c: New test.


-- 
Eric Botcazou
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr17245.diff
Type: text/x-diff
Size: 3249 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20041008/d0eaa890/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ultrasp11.c
Type: text/x-csrc
Size: 566 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20041008/d0eaa890/attachment-0001.bin>


More information about the Gcc-patches mailing list