Re: [ARM] Lack of __aeabi_fsqrt / __aeabi_dsqrt (sqrtsf2 / sqrtdf2) functions

2008-04-15 Thread Daniel Jacobowitz
On Wed, Apr 16, 2008 at 09:18:07AM +1000, Hasjim Williams wrote:
> glibc uses its own internal sqrt function, rather than the
> sqrtsf2/sqrtdf2 opcode, even on FPA or VFP.

Always.  That's how it is supposed to work; the expander allows GCC to
optimize sqrt operations inline, for architectures where it is
profitable to do so.  But the backing function remains "sqrt" (sqrtf,
sqrtl).  The implementation of that lives in the C library and is not
dependent on GCC for the body.

> Anyway, I misunderstood how the toolchain gets assembled and I would
> appreciate it someone could point out where the sqrt function is in
> glibc, on arm.
> Does arm use glibc/sysdeps/ieee754/dbl-64/mpsqrt.c ???

I don't know for sure, but it seems likely.  Build glibc with debug
info and step through it?

-- 
Daniel Jacobowitz
CodeSourcery


Re: [ARM] Lack of __aeabi_fsqrt / __aeabi_dsqrt (sqrtsf2 / sqrtdf2) functions

2008-04-15 Thread Hasjim Williams

On Tue, 15 Apr 2008 09:15:45 -0400, "Daniel Jacobowitz" <[EMAIL PROTECTED]>
said:
> 
> I'm going to keep asking until I get something we can work
> with... you're reporting a bug in the compiler, so we need a test case
> and the exact error message.  What is generating any kind of sqrt
> libcall?  There is nothing in GCC to call __aeabi_sqrt, which AFAIK
> does not exist.

gcc shouldn't call __aeabi_sqrt, since it doesn't exist.  It could
however try to do a libcall through the optab to sqrtsf2, since
sqrt_optab does exist in optabs.h/c and genopinit.c ...  

Ok, to try and test this out, I added this patch to gcc, and recompiled
gcc & glibc --with-fp for crunch:

--- gcc-4.2.2/gcc/config/arm/arm.md 2008-04-15 17:59:35.0
+1000
+++ gcc-4.2.2/gcc/config/arm/arm.md 2008-04-15 18:02:08.0
+1000
@@ -3100,6 +3100,22 @@
   "TARGET_ARM && TARGET_HARD_FLOAT && (TARGET_FPA || TARGET_VFP)"
   "")
 
+(define_expand "sqrtsf2_soft_insn"
+  [(set (match_operand:SF 0 "s_register_operand" "")
+   (sqrt:SF (match_operand:SF 1 "s_register_operand" "")))]
+  "TARGET_ARM && !(TARGET_HARD_FLOAT && (TARGET_FPA || TARGET_VFP))"
+  "{
+  FAIL;
+  }")
+
+(define_expand "sqrtdf2_soft_insn"
+  [(set (match_operand:DF 0 "s_register_operand" "")
+   (sqrt:DF (match_operand:DF 1 "s_register_operand" "")))]
+  "TARGET_ARM && !(TARGET_HARD_FLOAT && (TARGET_FPA || TARGET_VFP))"
+  "{
+  FAIL;
+  }")
+
 (define_insn_and_split "one_cmpldi2"
   [(set (match_operand:DI 0 "s_register_operand" "=&r,&r")
(not:DI (match_operand:DI 1 "s_register_operand" "?r,0")))]

I was expecting it to fail since now gcc shouldn't be able to expand
that operation.  I double check glibc config.status, and with_fp=yes.
So, I'm not sure how glibc is doing it's sqrt routines on arm.  In that
case I suspect that glibc doesn't call sqrt for VFP or FPA, then, and
you were right in your first e-mail.

glibc uses its own internal sqrt function, rather than the
sqrtsf2/sqrtdf2 opcode, even on FPA or VFP.

In any case if you want a test, then something like
gcc/testsuite/gcc.dg/arm-vfp1.c is enough (of course with different
dejagnu lines, e.g. dg-final scan-assembler lines) ...

I still think something like the above patch needs to be added to gcc,
just to ensure that the sqrtsf2 / sqrtdf2 libcall never happens, and an
error happens at compile time rather than runtime.  In the future glibc,
uclibc or some standalone function could make use of the "gcc" sqrt,
rather than the glibc sqrt.

Anyway, I misunderstood how the toolchain gets assembled and I would
appreciate it someone could point out where the sqrt function is in
glibc, on arm.
Does arm use glibc/sysdeps/ieee754/dbl-64/mpsqrt.c ???


Re: [ARM] Lack of __aeabi_fsqrt / __aeabi_dsqrt (sqrtsf2 / sqrtdf2) functions

2008-04-15 Thread Daniel Jacobowitz
On Tue, Apr 15, 2008 at 01:20:29PM +1000, Hasjim Williams wrote:
> Suffice to say, it will compile, but when you try to run it, and your
> program tries to do the libcall to the sqrt function it will segfault,
> because there is no libcall sqrt defined.
> 
> As far as I can tell, sqrt and div are the only major opcodes that are
> needed (for ieee754 glibc --with-fp) that aren't implemented in
> MaverickCrunch.

I'm going to keep asking until I get something we can work
with... you're reporting a bug in the compiler, so we need a test case
and the exact error message.  What is generating any kind of sqrt
libcall?  There is nothing in GCC to call __aeabi_sqrt, which AFAIK
does not exist.

-- 
Daniel Jacobowitz
CodeSourcery


Re: [ARM] Lack of __aeabi_fsqrt / __aeabi_dsqrt (sqrtsf2 / sqrtdf2) functions

2008-04-14 Thread Hasjim Williams

On Mon, 14 Apr 2008 23:09:00 -0400, "Daniel Jacobowitz" <[EMAIL PROTECTED]>
said:
> On Tue, Apr 15, 2008 at 12:58:40PM +1000, Hasjim Williams wrote:
> > Both FPA and VFP coprocessors implement sqrt opcodes:
> 
> So?  Glibc does not rely on that.  I've been building soft-float
> versions of glibc for non-Crunch targets for scarily close to a decade
> now, so this is clearly not the problem :-)  Please say what actual
> error you've encountered.

Of course you can build glibc and have it work correctly, as you are
configuring glibc --without-fp.  Try building glibc --with-fp and seeing
whether it works.

Suffice to say, it will compile, but when you try to run it, and your
program tries to do the libcall to the sqrt function it will segfault,
because there is no libcall sqrt defined.

As far as I can tell, sqrt and div are the only major opcodes that are
needed (for ieee754 glibc --with-fp) that aren't implemented in
MaverickCrunch.



Re: [ARM] Lack of __aeabi_fsqrt / __aeabi_dsqrt (sqrtsf2 / sqrtdf2) functions

2008-04-14 Thread Daniel Jacobowitz
On Tue, Apr 15, 2008 at 12:58:40PM +1000, Hasjim Williams wrote:
> Both FPA and VFP coprocessors implement sqrt opcodes:

So?  Glibc does not rely on that.  I've been building soft-float
versions of glibc for non-Crunch targets for scarily close to a decade
now, so this is clearly not the problem :-)  Please say what actual
error you've encountered.

-- 
Daniel Jacobowitz
CodeSourcery


Re: [ARM] Lack of __aeabi_fsqrt / __aeabi_dsqrt (sqrtsf2 / sqrtdf2) functions

2008-04-14 Thread Hasjim Williams
On Mon, 14 Apr 2008 22:41:36 -0400, "Daniel Jacobowitz" <[EMAIL PROTECTED]>
said:
> On Tue, Apr 15, 2008 at 12:33:38PM +1000, Hasjim Williams wrote:
> > Hello all,
> > 
> > I've been working on MaverickCrunch support in gcc, and could never get
> > a completely working glibc (with-fp), since there is no soft-float sqrt
> > libcall function.  This is a big problem for MaverickCrunch as there are
> > no hard div or sqrt opcodes.
> > 
> Can you be more specific about the actual problem?  I don't see why
> there needs to be an __aeabi_sqrt; sqrt is a function in libm.

Both FPA and VFP coprocessors implement sqrt opcodes:

arm.md:

(define_expand "sqrtsf2"
  [(set (match_operand:SF 0 "s_register_operand" "")
(sqrt:SF (match_operand:SF 1 "s_register_operand" "")))]
  "TARGET_32BIT && TARGET_HARD_FLOAT && (TARGET_FPA || TARGET_VFP)"
  "")

fpa.md:

(define_insn "*sqrtsf2_fpa"
  [(set (match_operand:SF 0 "s_register_operand" "=f")
(sqrt:SF (match_operand:SF 1 "s_register_operand" "f")))]
  "TARGET_32BIT && TARGET_HARD_FLOAT && TARGET_FPA"
  "sqt%?s\\t%0, %1"
  [(set_attr "type" "float_em")
   (set_attr "predicable" "yes")]
)

vfp.md:


(define_insn "*sqrtsf2_vfp"
  [(set (match_operand:SF0 "s_register_operand" "=t")
(sqrt:SF (match_operand:SF 1 "s_register_operand" "t")))]
  "TARGET_32BIT && TARGET_HARD_FLOAT && TARGET_VFP"
  "fsqrts%?\\t%0, %1"
  [(set_attr "predicable" "yes")
   (set_attr "type" "fdivs")]
)

Now, when you build glibc configured "--with-fp", you won't use the
generic glibc/soft-fp functions, only those in gcc, i.e. the above. 
Only if you configure glibc "--without-fp" will it not use the above
opcodes, but the soft-fp sqrt etc.


Re: [ARM] Lack of __aeabi_fsqrt / __aeabi_dsqrt (sqrtsf2 / sqrtdf2) functions

2008-04-14 Thread Daniel Jacobowitz
On Tue, Apr 15, 2008 at 12:33:38PM +1000, Hasjim Williams wrote:
> Hello all,
> 
> I've been working on MaverickCrunch support in gcc, and could never get
> a completely working glibc (with-fp), since there is no soft-float sqrt
> libcall function.  This is a big problem for MaverickCrunch as there are
> no hard div or sqrt opcodes.
> 
> It seems that this is the only other thing that is missing to let glibc
> be compiled with-fp for soft float arm, too.  
> 
> Is it possible to add these functions to ieee754-sf.S and ieee754-df.S
> ???  There is of course a c implementation in glibc/soft-fp but I don't
> know of any arm assembly implementation...
> 
> I know that ARM IHI 0043A doesn't specific this as part of the EABI, but
> perhaps it needs to be added?

Can you be more specific about the actual problem?  I don't see why
there needs to be an __aeabi_sqrt; sqrt is a function in libm.

-- 
Daniel Jacobowitz
CodeSourcery


[ARM] Lack of __aeabi_fsqrt / __aeabi_dsqrt (sqrtsf2 / sqrtdf2) functions

2008-04-14 Thread Hasjim Williams
Hello all,

I've been working on MaverickCrunch support in gcc, and could never get
a completely working glibc (with-fp), since there is no soft-float sqrt
libcall function.  This is a big problem for MaverickCrunch as there are
no hard div or sqrt opcodes.

It seems that this is the only other thing that is missing to let glibc
be compiled with-fp for soft float arm, too.  

Is it possible to add these functions to ieee754-sf.S and ieee754-df.S
???  There is of course a c implementation in glibc/soft-fp but I don't
know of any arm assembly implementation...

I know that ARM IHI 0043A doesn't specific this as part of the EABI, but
perhaps it needs to be added?

Thanks