------- Additional Comments From matz at suse dot de 2005-07-13 13:55 -------
I was going to add this text to PR22453, when I noticed that it was closed
as duplicate to this one. So putting it here for reference, although
everything seems to be analyzed already:
The reload happens, because reg 58 gets no hardreg, because it's live over
a call, and it's not worthwhile to put it into a call clobbered reg (which
SSE regs are). So reg 58 is placed onto stack (at ebp+16). Now this mem must
be initialized with 1.0. If that is done via x87 (fld1 , fst ebp+16), via
GENERAL_REGS (mov 1.0 -> (reg:DF ax) , mov (reg:DF ax) -> (ebp+16)), or via
SSE_REGS (movsd (mem 1.0) -> xmm0 , mov xmm0 -> (ebp+16)) is actually not
that important. You won't get rid of this reload.
Except that _if_ you force it to use SSE_REGS, then the next reload from
(ebp+16) for the next insn can be inherited (as it's then the same mode),
hence the initial store to ebp+16 is useless and will be removed.
This can be tested with this hack:
--- i386.md 12 Jul 2005 09:20:12 -0000 1.645
+++ i386.md 13 Jul 2005 13:47:06 -0000
@@ -2417,9 +2417,9 @@
(define_insn "*movdf_nointeger"
[(set (match_operand:DF 0 "nonimmediate_operand"
- "=f#Y,m ,f#Y,*r ,o ,Y*x#f,Y*x#f,Y*x#f ,m ")
+ "=?f#Y,m ,f#Y,*?r ,o ,Y*x#f,Y*x#f,Y*x#f ,m ")
(match_operand:DF 1 "general_operand"
- "fm#Y,f#Y,G ,*roF,F*r,C ,Y*x#f,HmY*x#f,Y*x#f"))]
+ "?fm#Y,f#Y,G ,*?roF,F*r,C ,Y*x#f,HmY*x#f,Y*x#f"))]
"(GET_CODE (operands[0]) != MEM || GET_CODE (operands[1]) != MEM)
&& ((optimize_size || !TARGET_INTEGER_DFMODE_MOVES) && !TARGET_64BIT)
&& (reload_in_progress || reload_completed
But I don't see immediately how reload could be convinced to do so
automatically, as the choice of the reload class for one insn is independend
from the choices of reloads for the same reg but in other insns.
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |matz at suse dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19653
