This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 

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?


2006-07-06  Paul Brook  <>

	* config/m68k/ Add r-m patterns for 68881 movxf.

Index: gcc/config/m68k/
--- gcc/config/m68k/	(revision 115205)
+++ gcc/config/m68k/	(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"))]
   if (FP_REG_P (operands[0]))

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]