[OE-core] libm accuracy, eglibc compared to glibc -- solved

[Khem Raj]

On Mar 27, 2014 8:16 AM, "Mats Kärrman" <Mats.Karrman at 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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20140327/d20a5e3b/attachment-0002.html>