"Naveen H. S" wrote:
> Software floating point(libgcc) routines were implemented for SH in the
> following links:-
> http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00063.html
> http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00614.html
> http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00624.html
>
> Ther
Quoting Kaz Kojima :
but in general the maintenance of
hand crafted assembly codes will be hard.
If you have a fixed feature set and pipeline, and have made sure the code
is correct, no further maintenance should be required - which is more
than can be said of the target port code generator, wh
Quoting "Naveen H. S" :
extendsfdf2 - gcc.c-torture/execute/conversion.c
gcc.dg/torture/fp-int-convert-float.c, gcc.dg/pr28796-2.c
Note that some tests invoke undefined behaviour; I've also come across this
when doing optimized soft FP for ARCompact:
http://gcc.gnu.org/viewcvs/branches/arc-4_
"Naveen H. S" wrote:
>>> you can free to propose a complete and regtested patch for SH
>>> assembly soft fp against trunk.
>
> Please find attached the ported soft float patch "sh_softfloat.patch".
> The original patch was posted at the following link by Joern RENNECKE.
> http://gcc.gnu.org/ml/
Quoting Kaz Kojima :
sh_softfp.patch looks basically OK to me, though I'm curious
with numbers for fp-bit.c/softfp/softfloat. Could you show us
some real speed&size numbers?
I don't have any sh[1234] hardware to EEMBC tests on, but the runtime
difference of 'make check' on i686-pc-linux-gnu X
Joern Rennecke wrote:
> I don't have any sh[1234] hardware to EEMBC tests on, but the runtime
> difference of 'make check' on i686-pc-linux-gnu X sh-elf using a core2 quad
> for fp-bit vs. softfloat (w/ compare/conversion/divsf) is two hours 4 minutes
> versus 38 minutes.
Very impressive. Thanks
Hi.
Thank you for the modified patch.
I have applied the patch to gcc-4.5 sources and checking the regression
for SH[1234].
I will run some more tests on the modified (patched) toolchain.
I will share the test results after the regression and other tests are
complete.
Regards,
Naveen
Joern Rennecke wrote:
> I've found two bugs in truncdfsf2;
> I've also added back a number of hunks that Naveen had dropped.
>
> Note that most of the patch has been prepared in 2006, so that is the
> proper most recent copyright date for those files that haven't been touched
> save for swapping
Hi Kaz,
Kaz Kojima wrote:
BTW, it looks that softfp __unord?f2 routines check signaling NaNs
only. This makes __builtin_isnan return false for quiet NaNs for
which current fp-bit ones return true when -mieee enabled. Perhaps
that change of behavior might be OK for software FP.
I use the at
> I'm trying the attached patch over sh-softfp-20100718-2131 patch.
> All regressions go away with it on cross sh4-unknown-linux-gnu,
> though the native bootstrap will take a few days more.
There are a few warnings in bootstrap:
../trunk/gcc/config/sh/sh.c: In function 'sh_soft_fp_cmp':
../trunk
Quoting Kaz Kojima :
I've got some regressions with "make check" on sh4-unknown-linux-gnu.
It looks that all of them are failed with the undefined references to
__unorddf2/__unordsf2 when -mieee enabled.
That's a bug, then; we shouldn't use a library function there,
but the cmpordered[sd]f_t_4
Christian Bruel wrote:
Hi Kaz,
Kaz Kojima wrote:
BTW, it looks that softfp __unord?f2 routines check signaling NaNs
only. This makes __builtin_isnan return false for quiet NaNs for
which current fp-bit ones return true when -mieee enabled. Perhaps
that change of behavior might be OK for sof
Quoting Christian Bruel :
Edited to apply on top of latest Joern's patch. Certainly not optimal
but it fixes the QNaNs checks for builtins and inlined unordered
comparisons for -mieee or -fno-inite-math-only.
You are still on the wrong track; as I said in my earlier message, we
should not emit
Joern Rennecke wrote:
Quoting Christian Bruel :
Edited to apply on top of latest Joern's patch. Certainly not optimal
but it fixes the QNaNs checks for builtins and inlined unordered
comparisons for -mieee or -fno-inite-math-only.
You are still on the wrong track; as I said in my earlier mess
Joern Rennecke wrote:
> That's a bug, then; we shouldn't use a library function there,
> but the cmpordered[sd]f_t_4 patterns.
Argh, I've missed the required patterns are incorporated already
in your patch. I'll test it again with sh-softfp-predicate-fix
when the tests for 4.5.1-rc are done. Th
oops, resending it with a small typo fix (a branch became delayed :-().
Just in case it we accepted that SNaNs and QNaNs are not exclusive and
mimic the C model, a synthetic illustrative test case:
Compile with
sh-superh-elf-gcc -O2 -mieee -m4-nofpu snan.c snan2.c -g -o l.u ;
sh-superh-elf-ru
Quoting Christian Bruel :
> About the other part of your answer, non supporting SNaNs in the
fp-bit.c, it is a possibility that I didn't consider in my fix. This
restriction is quite a surprise to me because, related to NaNs, it is
not what I guess from the implementation of the fp-bit.c's isna
Quoting Christian Bruel :
Using the ieee-sf.S + this patch
OK
Is this only a proof-of-concept, because you only change the ne[sd]f2
implementation? And you go out of your way to only accept a restricted
set of values. Plus, the overuse of the arithmetic unit hurts SH4-100 /
SH4-200 instru
Quoting Christian Bruel :
oops, resending it with a small typo fix (a branch became delayed :-().
For an actual patch, you need to use the SL* macros from
config/sh/lib1funcs.h because the SH1 does not have delayed branches.
On Fri, 16 Jul 2010, Joern Rennecke wrote:
> Quoting "Naveen H. S" :
>
> > extendsfdf2 - gcc.c-torture/execute/conversion.c
> > gcc.dg/torture/fp-int-convert-float.c, gcc.dg/pr28796-2.c
>
> Note that some tests invoke undefined behaviour; I've also come across this
> when doing optimized soft FP
Quoting "Joseph S. Myers" :
That diff does not appear to relate to undefined behavior. GCC considers
these out-of-range conversions to yield an unspecified value, possibly
raising an exception, as per Annex F, and does not take the liberty of
optimizing on the basis of them being undefined when
On Thu, 22 Jul 2010, Joern Rennecke wrote:
> Quoting "Joseph S. Myers" :
>
> > That diff does not appear to relate to undefined behavior. GCC considers
> > these out-of-range conversions to yield an unspecified value, possibly
> > raising an exception, as per Annex F, and does not take the liber
Joern Rennecke wrote:
Quoting Christian Bruel :
Using the ieee-sf.S + this patch
OK
Is this only a proof-of-concept, because you only change the ne[sd]f2
implementation?
I changed also the unordered comparison patterns. (cmpunsf_i1,
cmpundf_i1). But yes, the other functions that would
> Joern Rennecke wrote:
>> That's a bug, then; we shouldn't use a library function there,
>> but the cmpordered[sd]f_t_4 patterns.
>
> Argh, I've missed the required patterns are incorporated already
> in your patch. I'll test it again with sh-softfp-predicate-fix
> when the tests for 4.5.1-rc a
Hi,
>> I've tested sh-softfp-20100718-2131 + sh-softfp-predicate-fix
>> on -m1, -m2, -m3, -m3 -ml, -m2a on sh-elf, sh4-linux and
>> sh64-linux
The SH toolchain was built with the following patches and regression
is completed.
1. sh-softfp-20100718-2131
2. sh-softfp-predicate-fix
3. Patch by Kaz
"Naveen H. S" wrote:
> The SH toolchain was built with the following patches and regression
> is completed.
> 1. sh-softfp-20100718-2131
> 2. sh-softfp-predicate-fix
> 3. Patch by Kaz Kojima-san at following link
> http://gcc.gnu.org/ml/gcc/2010-07/msg00352.html
Thanks for testing.
> However, th
26 matches
Mail list logo
