[OE-core] 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 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
------------------------------------------------------------------------------
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