This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Which POWER implementations need the HWCAP_DFP check?
Florian Weimer <fweimer@redhat.com> writes:
> On 05/14/2018 05:22 PM, Tulio Magno Quites Machado Filho wrote:
>> Florian Weimer <fweimer@redhat.com> writes:
>>
>>> In particularly, we do not need it on ppc64le. Correct?
>>
>> Agreed, unless the kernel has the right to disable DFP support.
>
> Ugh, I had not thought of that. Isn't DFP support part of the userspace
> ABI?
The bit PPC_FEATURE_HAS_DFP is indeed part of the ABI.
But I don't think we can say the whole DFP support is also part of the ABI,
because both powerpc and powerpc64 ABIs have to work on processors that do
not support DFP.
Although all IBM POWER processors since POWER6 do support it, that may not be
true for all processors from all manufacturers.
Anyway, I think we started to diverge from the actual topic after my previous
comment. I apologize. :-)
>>> It's one of the GLIBC_PRIVATE references in libm.so.6, which is why I'm
>>> asking.
>>
>> Would the following code solve this problem?
>>
>> #include <tls.h>
>> /* Equivalent to fesetenv, but takes a fenv_t instead of a pointer. */
>> #define fesetenv_register(env) \
>> do { \
>> double d = (env); \
>> if(THREAD_GET_HWCAP() & PPC_FEATURE_HAS_DFP) \
>> asm volatile (".machine push; " \
>> ".machine \"power6\"; " \
>> "mtfsf 0xff,%0,1,0; " \
>> ".machine pop" : : "f" (d)); \
>> else \
>> asm volatile ("mtfsf 0xff,%0" : : "f" (d)); \
>> } while(0)
>
> It avoids the GLIBC_PRIVATE reference, but it does not avoid the
> dependency on library internals. So in a certain sense, it is way worse
> than what we have today (in particular if you are interested in pre-2.23
> glibc versions still).
OK.
> I would have suggested something like
>
> #define DL_HWCAP_HAS_DFP (GLRO(dl_hwcap) & PPC_FEATURE_HAS_DFP)
>
> in the general powerpc sysdeps file, and
>
> #define DL_HWCAP_HAS_DFP 1
>
> for power6 (which I expect will propagate upwards). I expect that this
> will result in somewhat nicer machine code, too.
It's safe to use the newer mtfsf in both cases. The extra fields from the
new mtfsf are ignored by older processors.
--
Tulio Magno