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.
