Re: libm accuracy, eglibc compared to glibc -- solved

Re: libm accuracy, eglibc compared to glibc -- solved

[Mats Kärrman]

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?

Would it be worthwhile to send a patch to add the hf tuning to OE-core?

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

BR // Mats

Re: libm accuracy, eglibc compared to glibc -- solved

[Mark Hatle]

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

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

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

Re: libm accuracy, eglibc compared to glibc -- solved

[Khem Raj]

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.

>
>
>> In that case what tests should be performed before that and what (related)
>> tests are performed by the OE auto-builder?
>>
>> BR // Mats
>>
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: libm accuracy, eglibc compared to glibc -- solved

[Mats Kärrman]

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

Re: libm accuracy, eglibc compared to glibc -- solved

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 3888 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 5589 bytes --]