Patchwork libm accuracy, eglibc compared to glibc -- solved

login
register
mail settings
Submitter Mats Kärrman
Date March 27, 2014, 3:16 p.m.
Message ID <ED3E0BCACD909541BA94A34C4A164D4C5B3A7257@post.tritech.se>
Download mbox | patch
Permalink /patch/69407/
State New
Headers show

Comments

Mats Kärrman - March 27, 2014, 3:16 p.m.
Hi Khem,

On Friday, March 21, 2014 6:06 PM, Khem Raj wrote:
> On Fri, Mar 21, 2014 at 9:45 AM, Mark Hatle <mark.hatle@windriver.com> wrote:
>> On 3/21/14, 7:10 AM, Mats Kärrman wrote:
>>>
>>> Hi,
>>>
>>> On: Thursday, March 13, 2014 11:36 AM, Mats Kärrman wrote:
>>>>
>>>> My "home made" hard float tune for PowerPC looks like this:
>>>>
>>>> ------------------------------------------------------------------
>>>> # Tune for the e300c3 core
>>>> require conf/machine/include/tune-ppce300c3.inc
>>>>
>>>> # Use hardware floating point
>>>> AVAILTUNES += "ppce300c3hf"
>>>> TUNE_FEATURES_tune-ppce300c3hf = "m32 fpu-hard ppce300c3"
>>>> TUNE_PKGARCH_tune-ppce300c3hf = "ppce300c3hf"
>>>> PACKAGE_EXTRA_ARCHS_tune-ppce300c3hf =
>>>> "${PACKAGE_EXTRA_ARCHS_tune-powerpc} ppce300c3hf"
>>>> DEFAULTTUNE = "ppce300c3hf"
>>>> ------------------------------------------------------------------
>>>>
>>>
>>> I found the reason for the error (deviance) in the sqrt function. glibc
>>> has
>>> special code for PowerPC 603e core (e300 is an optimized variant of 603e).
>>> By adding the following line to the tuning I now get the same result as
>>> for all other environments that I've tried:
>>>
>>> GLIBC_EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppce300c3",
>>> "-with-cpu=603e", "", d)}"
>>>
>>> Does anyone know about the reason for having soft-float as the default and
>>> only available alternative for e300c2/3 tunings?
>>
>>
>> My guess is because e300 e300c2 were both soft-float designs.  And e300c3 is
>> the first hard float design.
>>
>> The e300c3 should inherit and use the 603e directly.  This includes
>> definiting the TUNE_FEATURES that the 603e does.  If it doesn't do that, I'd
>> suggest it's a mistake.
>>
>> The default 603e tune should include:
>>
>> GLIBC_EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppc603e",
>> "-with-cpu=603e", "", d)}"
>>
>> or similar already -- and should already be hard float enabled.  (ppc603e
>> soft-float should be the alternative -- as it is significantly rarer and the
>> deviation.)
>
>
> alternatively we should define fpu Iplies in glibc for e300c3,
>
>>
>>
>>> Would it be worthwhile to send a patch to add the hf tuning to OE-core?
>>
>>
>> As the e300c3 should be hard float, we shouldn't have the 'hf' designation.
>> Otherwise, we should ensure the e300c3 tune is correctly configured.
>
> may be for now controlling it in tune file is a quicker fix.
>

Adding "-with-cpu=603e" to GLIBC_EXTRA_OECONF proved to be problematic
as it leads to contradictive --mcpu= args to gcc, both "e300c3" and "603e".

I solved that by using "-with-cpu=e300c3" and by adding a patch to eglibc:
------------------------------------------------------------------------------
------------------------------------------------------------------------------
Does this seem correct to you?

Initial tests shows that at least the sqrt test now works. The reason
I'm holding back on patches to the tune file is that I still have trouble
with time related syscalls, see [1].

>>
>>> In that case what tests should be performed before that and what (related)
>>> tests are performed by the OE auto-builder?

BR // Mats

[1] http://lists.openembedded.org/pipermail/openembedded-core/2014-March/091011.html
Khem Raj - March 27, 2014, 4 p.m.
On Mar 27, 2014 8:16 AM, "Mats Kärrman" <Mats.Karrman@tritech.se> wrote:
>
> Hi Khem,
>
> On Friday, March 21, 2014 6:06 PM, Khem Raj wrote:
> > On Fri, Mar 21, 2014 at 9:45 AM, Mark Hatle <mark.hatle@windriver.com>
wrote:
> >> On 3/21/14, 7:10 AM, Mats Kärrman wrote:
> >>>
> >>> Hi,
> >>>
> >>> On: Thursday, March 13, 2014 11:36 AM, Mats Kärrman wrote:
> >>>>
> >>>> My "home made" hard float tune for PowerPC looks like this:
> >>>>
> >>>> ------------------------------------------------------------------
> >>>> # Tune for the e300c3 core
> >>>> require conf/machine/include/tune-ppce300c3.inc
> >>>>
> >>>> # Use hardware floating point
> >>>> AVAILTUNES += "ppce300c3hf"
> >>>> TUNE_FEATURES_tune-ppce300c3hf = "m32 fpu-hard ppce300c3"
> >>>> TUNE_PKGARCH_tune-ppce300c3hf = "ppce300c3hf"
> >>>> PACKAGE_EXTRA_ARCHS_tune-ppce300c3hf =
> >>>> "${PACKAGE_EXTRA_ARCHS_tune-powerpc} ppce300c3hf"
> >>>> DEFAULTTUNE = "ppce300c3hf"
> >>>> ------------------------------------------------------------------
> >>>>
> >>>
> >>> I found the reason for the error (deviance) in the sqrt function.
glibc
> >>> has
> >>> special code for PowerPC 603e core (e300 is an optimized variant of
603e).
> >>> By adding the following line to the tuning I now get the same result
as
> >>> for all other environments that I've tried:
> >>>
> >>> GLIBC_EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES",
"ppce300c3",
> >>> "-with-cpu=603e", "", d)}"
> >>>
> >>> Does anyone know about the reason for having soft-float as the
default and
> >>> only available alternative for e300c2/3 tunings?
> >>
> >>
> >> My guess is because e300 e300c2 were both soft-float designs.  And
e300c3 is
> >> the first hard float design.
> >>
> >> The e300c3 should inherit and use the 603e directly.  This includes
> >> definiting the TUNE_FEATURES that the 603e does.  If it doesn't do
that, I'd
> >> suggest it's a mistake.
> >>
> >> The default 603e tune should include:
> >>
> >> GLIBC_EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "ppc603e",
> >> "-with-cpu=603e", "", d)}"
> >>
> >> or similar already -- and should already be hard float enabled.
 (ppc603e
> >> soft-float should be the alternative -- as it is significantly rarer
and the
> >> deviation.)
> >
> >
> > alternatively we should define fpu Iplies in glibc for e300c3,
> >
> >>
> >>
> >>> Would it be worthwhile to send a patch to add the hf tuning to
OE-core?
> >>
> >>
> >> As the e300c3 should be hard float, we shouldn't have the 'hf'
designation.
> >> Otherwise, we should ensure the e300c3 tune is correctly configured.
> >
> > may be for now controlling it in tune file is a quicker fix.
> >
>
> Adding "-with-cpu=603e" to GLIBC_EXTRA_OECONF proved to be problematic
> as it leads to contradictive --mcpu= args to gcc, both "e300c3" and
"603e".
>
> I solved that by using "-with-cpu=e300c3" and by adding a patch to eglibc:
>
------------------------------------------------------------------------------
> --- libc.orig/ports/sysdeps/powerpc/powerpc32/e300c3/fpu/Implies
> +++ libc/ports/sysdeps/powerpc/powerpc32/e300c3/fpu/Implies
> @@ -0,0 +1,2 @@
> +# e300c3 is a variant of 603e so use the same optimizations for sqrt
> +powerpc/powerpc32/603e/fpu

yes thats ok

>
------------------------------------------------------------------------------
> Does this seem correct to you?
>
> Initial tests shows that at least the sqrt test now works. The reason
> I'm holding back on patches to the tune file is that I still have trouble
> with time related syscalls, see [1].
>
> >>
> >>> In that case what tests should be performed before that and what
(related)
> >>> tests are performed by the OE auto-builder?
>
> BR // Mats
>
> [1]
http://lists.openembedded.org/pipermail/openembedded-core/2014-March/091011.html
>

Patch

--- libc.orig/ports/sysdeps/powerpc/powerpc32/e300c3/fpu/Implies
+++ libc/ports/sysdeps/powerpc/powerpc32/e300c3/fpu/Implies
@@ -0,0 +1,2 @@ 
+# e300c3 is a variant of 603e so use the same optimizations for sqrt
+powerpc/powerpc32/603e/fpu