Float commands for 64bit data

[Andrew Haley]

Fabian Cenedese writes:
 > At 09:58 11.12.2006 +0000, Andrew Haley wrote:
 > >Fabian Cenedese writes:
 > > > At 14:33 07.12.2006 +0100, Fabian Cenedese wrote:
 > > > >Hi
 > > > >
 > > > >Is there a flag to tell gcc NOT to use float assembler commands
 > > > >for 64bit data? We have problems that the generated code contains
 > > > >float commands while the target (partially) has no float support.
 > > > >
 > > > >The float commands are simply used for moving 64 bit of data around.
 > > > >That may be faster than 2x32 but not working here. I'm interested in
 > > > >workarounds for various gcc versions (2.95, 3.4, 4.x).
 > > > 
 > > > Doesn't anybody know a way around this? Or has the same problem?
 > >
 > >I guess we're having difficulty understanding why -msoft-float is not
 > >appropriate for you.  It seems to me obviously the right thing to do
 > >with a target (partially) without float support.
 > 
 > I quote here from the old mail:
 > 
 > --------------------
 > In our kernel I can create tasks with floating point enabled or
 > disabled. If I don't need floating numbers in a task I disable them
 > to improve task switches (much faster because the kernel doesn't
 > have to save/restore the 32 floating point registers of the PPC603).
 > So my problem is if I work with 64 Bit integers or stuctures in a
 > task with floating support disabled this task stops with a floating
 > point exception.
 > --------------------
 > 
 > PPC603 of course has a FPU and we make good use of it. But there
 > are some tasks that don't need float/double, so we disable the
 > floating point support on those tasks (see above). But as the FPU
 > registers are not saved on a task switch it can happen that they
 > get destroyed if a task switch happens right between the lfd/stfd
 > (and we sure had that).
 > 
 > Generally using -msoft-float would change all float calculations
 > and therefore make the whole program slower. That's not possible on
 > axis controllers that are already at the limit of the CPU. And
 > there are also (inline) functions that get used from both floating
 > point enabled and disabled tasks.
 > 
 > The best thing for us would be some kind of -msoft-float-ll which
 > would only affect the (mis)use of the FPU for moving 64bit long
 > longs around but leave the real float calculations intact. The
 > second best may be a pragma or attribute for explicit code
 > sections. If there is no such thing we would also change the gcc
 > code itself if this code generation is in a central place. Of
 > course we would prefer to use the vanilla gcc.

OK, all that makes sense.

The easiest way to do that is simply to disable the patterns that
generate the floating-point operations.  I think the pattern is this
one:

(define_insn "*movdi_internal64"
  [(set (match_operand:DI 0 "nonimmediate_operand" "=r,r,m,r,r,r,r,*f,*f,m,r,*h,*h")
	(match_operand:DI 1 "input_operand" "r,m,r,I,L,nF,R,f,m,f,*h,r,0"))]
  "TARGET_POWERPC64
   && (gpc_reg_operand (operands[0], DImode)
       || gpc_reg_operand (operands[1], DImode))"
  "@
   mr %0,%1
   ld%U1%X1 %0,%1
   std%U0%X0 %1,%0
   li %0,%1
   lis %0,%v1
   #
   {cal|la} %0,%a1
   fmr %0,%1
   lfd%U1%X1 %0,%1
   stfd%U0%X0 %1,%0
   mf%1 %0
   mt%0 %1
   {cror 0,0,0|nop}"
  [(set_attr "type" "*,load,store,*,*,*,*,fp,fpload,fpstore,mfjmpr,mtjmpr,*")
   (set_attr "length" "4,4,4,4,4,20,4,4,4,4,4,4,4")])

You'd want to remove the operations with "f" in their constraint
pattern: that is, no. 8 and 9.  An alternative idea would be to alter
the cost of the opration so that the compiler never chooses to put a
float in an int register.

Andrew.