This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
m68k xfmode ice (PR27991)
- From: Paul Brook <paul at codesourcery dot com>
- To: gcc-patches at gcc dot gnu dot org, schwab at suse dot de
- Date: Thu, 6 Jul 2006 17:18:12 +0100
- Subject: m68k xfmode ice (PR27991)
The patch belowfixes PR27991 (a regression from 4.1).
This appears to be a latent bug triggered by adding a "d" alternative to the
negxf pattern. This causes the register allocator to make different register
choices, and ends up wanting to move an XFmode value from integer regs to
memory.
I see two possible solutions:
a) Add r<->m alternatives to the movxf pattern. It appears that
output_move_double [sic] already knows how to move XFmode values between
memory and integer registers. This is what I have implemented.
b) Define TARGET_SECONDARY_RELOAD to use an intermediate "f" register for
XFmode values. As f<->r moves go via memory this would be vastly sub-optimal.
I don't have access to 68881 hardware, so can't really test this patch
properly. I've built m68k-elf and verified by inspection that the testcase in
the PR passes. Additional testing would be appreciated.
Ok for mainline?
Paul
2006-07-06 Paul Brook <paul@codesourcery.com>
* config/m68k/m68k.md: Add r-m patterns for 68881 movxf.
Index: gcc/config/m68k/m68k.md
===================================================================
--- gcc/config/m68k/m68k.md (revision 115205)
+++ gcc/config/m68k/m68k.md (working copy)
@@ -1085,8 +1085,8 @@ (define_expand "movxf"
})
(define_insn ""
- [(set (match_operand:XF 0 "nonimmediate_operand" "=f,m,f,!r,!f,!r")
- (match_operand:XF 1 "nonimmediate_operand" "m,f,f,f,r,!r"))]
+ [(set (match_operand:XF 0 "nonimmediate_operand" "=f,m,f,!r,!f,!r,m,!r")
+ (match_operand:XF 1 "nonimmediate_operand" "m,f,f,f,r,!r,!r,m"))]
"TARGET_68881"
{
if (FP_REG_P (operands[0]))