Float commands for 64bit data

Float commands for 64bit data

[Fabian Cenedese]

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.

To make it clear: This is not about the soft-float library which would
emulate float commands. We don't want gcc to even generate
those unless it really is about float operations.

Here's one example (for PPC603), but there also are others:

inline uint64 GetSystemTicks()
{
	union {
		uint64 s;
		struct {
			uint32 high;
			uint32 low;
		} m;
	} result;

	uint32 tmp=0;
	asm volatile (
		"mftbu 	%0" "\n\t"
		"mftb 	%1" "\n\t"
		"mftbu	%2" "\n\t"
		"cmpw	%3,%4" "\n\t"
		"beq	0f" "\n\t"
		"mftbu 	%0" "\n\t"
		"mftb 	%1" "\n\t"
	"0:"	 
		: "=r" (result.m.high), "=r" (result.m.low), "=r" (tmp)
		: "0" (result.m.high), "2" (tmp));

	return result.s;
}

...(snip)...
	mr 0,10			 # tmp120,
	stw 0,8(31)		 # result.m.high, tmp120
	stw 9,12(31)		 # result.m.low, tmp121
	stw 11,16(31)		 # tmp, tmp122
->	lfd 0,8(31)		 # result.s, result.s
->	stfd 0,24(31)		 #, result.s
	lwz 9,24(31)		 #, <result>
	lwz 10,28(31)		 #, <result>
	mr 3,9			 # <result>, <result>
	mr 4,10			 # <result>, <result>
	lwz 11,0(1)		 #,
	lwz 31,-4(11)		 #,
	mr 1,11			 #,
	blr			 #

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).

Thanks

bye   Fabi

Re: Float commands for 64bit data

[Fabian Cenedese]

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.
>
>To make it clear: This is not about the soft-float library which would
>emulate float commands. We don't want gcc to even generate
>those unless it really is about float operations.
>
>Here's one example (for PPC603), but there also are others:
>
>inline uint64 GetSystemTicks()
>{
>        union {
>                uint64 s;
>                struct {
>                        uint32 high;
>                        uint32 low;
>                } m;
>        } result;
>
>        uint32 tmp=0;
>        asm volatile (
>                "mftbu  %0" "\n\t"
>                "mftb   %1" "\n\t"
>                "mftbu  %2" "\n\t"
>                "cmpw   %3,%4" "\n\t"
>                "beq    0f" "\n\t"
>                "mftbu  %0" "\n\t"
>                "mftb   %1" "\n\t"
>        "0:"    
>                : "=r" (result.m.high), "=r" (result.m.low), "=r" (tmp)
>                : "0" (result.m.high), "2" (tmp));
>
>        return result.s;
>}
>
>...(snip)...
>        mr 0,10                 # tmp120,
>        stw 0,8(31)             # result.m.high, tmp120
>        stw 9,12(31)            # result.m.low, tmp121
>        stw 11,16(31)           # tmp, tmp122
>->      lfd 0,8(31)             # result.s, result.s
>->      stfd 0,24(31)           #, result.s
>        lwz 9,24(31)            #, <result>
>        lwz 10,28(31)           #, <result>
>        mr 3,9                  # <result>, <result>
>        mr 4,10                 # <result>, <result>
>        lwz 11,0(1)             #,
>        lwz 31,-4(11)           #,
>        mr 1,11                 #,
>        blr                     #
>
>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?

The issue is not new as seen here:
http://gcc.gnu.org/ml/gcc-help/2000-10/msg00166.html
http://gcc.gnu.org/ml/gcc-bugs/2000-10/msg00546.html

Thanks for any ideas (even changing gcc source code).

bye  Fabi

Re: Float commands for 64bit data

[Andrew Haley]

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.
 > >
 > >To make it clear: This is not about the soft-float library which would
 > >emulate float commands. We don't want gcc to even generate
 > >those unless it really is about float operations.
 > >
 > >Here's one example (for PPC603), but there also are others:
 > >
 > >inline uint64 GetSystemTicks()
 > >{
 > >        union {
 > >                uint64 s;
 > >                struct {
 > >                        uint32 high;
 > >                        uint32 low;
 > >                } m;
 > >        } result;
 > >
 > >        uint32 tmp=0;
 > >        asm volatile (
 > >                "mftbu  %0" "\n\t"
 > >                "mftb   %1" "\n\t"
 > >                "mftbu  %2" "\n\t"
 > >                "cmpw   %3,%4" "\n\t"
 > >                "beq    0f" "\n\t"
 > >                "mftbu  %0" "\n\t"
 > >                "mftb   %1" "\n\t"
 > >        "0:"    
 > >                : "=r" (result.m.high), "=r" (result.m.low), "=r" (tmp)
 > >                : "0" (result.m.high), "2" (tmp));
 > >
 > >        return result.s;
 > >}
 > >
 > >...(snip)...
 > >        mr 0,10                 # tmp120,
 > >        stw 0,8(31)             # result.m.high, tmp120
 > >        stw 9,12(31)            # result.m.low, tmp121
 > >        stw 11,16(31)           # tmp, tmp122
 > >->      lfd 0,8(31)             # result.s, result.s
 > >->      stfd 0,24(31)           #, result.s
 > >        lwz 9,24(31)            #, <result>
 > >        lwz 10,28(31)           #, <result>
 > >        mr 3,9                  # <result>, <result>
 > >        mr 4,10                 # <result>, <result>
 > >        lwz 11,0(1)             #,
 > >        lwz 31,-4(11)           #,
 > >        mr 1,11                 #,
 > >        blr                     #
 > >
 > >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.

Andrew.

Re: Float commands for 64bit data

[Fabian Cenedese]

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.

Moving all those critical code parts into one file that can be compiled
with -msoft-float may be doable for our OS (thought not really usable
as we enable/disable functionality by including/excluding files from
linking). But for our (not always C++-savy) customers it can't be the
solution. "Your self-written code crashes? Just use -msoft-float.
It will be much slower but work." That's why I'm looking for a general
solution.

Thanks

bye   Fabi

Re: 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.

Re: Float commands for 64bit data

[Andrew Haley]

Andrew Haley writes:
 > 
 > 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.

8, 9, and 10.

 > 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.

Re: Float commands for 64bit data

[Fabian Cenedese]

> > 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:
>
>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.

Thanks for the directions. We'll try it out and let you know how it
works once we find our way around the gcc source code, but that
may take some time.

Thanks again

bye  Fabi

Re: Float commands for 64bit data

[Rask Ingemann Lambertsen]

On Thu, Dec 07, 2006 at 02:33:04PM +0100, Fabian Cenedese wrote:

> 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.
[snip]
> 
> 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).

   You can use -ffixed-fr0, -ffixed-fr1 and so on for each file which must
be compiled without use of floating point instructions, including
floating point load/store.

-- 
Rask Ingemann Lambertsen