* Re: libm accuracy, eglibc compared to glibc -- solved
@ 2014-03-21 12:10 Mats Kärrman
2014-03-21 16:45 ` Mark Hatle
0 siblings, 1 reply; 5+ messages in thread
From: Mats Kärrman @ 2014-03-21 12:10 UTC (permalink / raw)
To: openembedded-core@lists.openembedded.org
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
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: libm accuracy, eglibc compared to glibc -- solved 2014-03-21 12:10 libm accuracy, eglibc compared to glibc -- solved Mats Kärrman @ 2014-03-21 16:45 ` Mark Hatle 2014-03-21 17:06 ` Khem Raj 0 siblings, 1 reply; 5+ messages in thread From: Mark Hatle @ 2014-03-21 16:45 UTC (permalink / raw) To: openembedded-core 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 > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: libm accuracy, eglibc compared to glibc -- solved 2014-03-21 16:45 ` Mark Hatle @ 2014-03-21 17:06 ` Khem Raj 2014-03-27 15:16 ` Mats Kärrman 0 siblings, 1 reply; 5+ messages in thread From: Khem Raj @ 2014-03-21 17:06 UTC (permalink / raw) To: Mark Hatle; +Cc: Patches and discussions about the oe-core layer 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: libm accuracy, eglibc compared to glibc -- solved 2014-03-21 17:06 ` Khem Raj @ 2014-03-27 15:16 ` Mats Kärrman 2014-03-27 16:00 ` Khem Raj 0 siblings, 1 reply; 5+ messages in thread From: Mats Kärrman @ 2014-03-27 15:16 UTC (permalink / raw) To: Khem Raj; +Cc: Patches and discussions about the oe-core layer 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: libm accuracy, eglibc compared to glibc -- solved 2014-03-27 15:16 ` Mats Kärrman @ 2014-03-27 16:00 ` Khem Raj 0 siblings, 0 replies; 5+ messages in thread From: Khem Raj @ 2014-03-27 16:00 UTC (permalink / raw) To: Mats Kärrman; +Cc: Patches and discussions about the oe-core layer [-- 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 --] ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-03-27 16:00 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-03-21 12:10 libm accuracy, eglibc compared to glibc -- solved Mats Kärrman 2014-03-21 16:45 ` Mark Hatle 2014-03-21 17:06 ` Khem Raj 2014-03-27 15:16 ` Mats Kärrman 2014-03-27 16:00 ` Khem Raj
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.