[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <0a73b895-5d34-0059-0355-397e0abf0d3e@linaro.org>
Date: Sun, 2 Oct 2016 10:59:00 -0300
From: Adhemerval Zanella <adhemerval.zanella@...aro.org>
To: musl@...ts.openwall.com
Subject: Re: Model specific optimizations?
On 01/10/2016 16:53, Markus Wichmann wrote:
> On Sat, Oct 01, 2016 at 11:10:12AM -0400, Rich Felker wrote:
>> On Sat, Oct 01, 2016 at 10:52:14AM +0200, Markus Wichmann wrote:
>>> On Sat, Oct 01, 2016 at 01:50:23AM -0400, Rich Felker wrote:
>>>> I don't think this works at all. sqrt() is required to be
>>>> correctly-rounded; that's the whole reason sqrt.c is costly.
>>>
>>> It's an approximation, at least, which was rather my point.
>>>
>>> As I've come to realize over the course of this discussion, the fsqrt
>>> instruction is useless here and pretty much everywhere out there:
>>
>> I don't think that conclusion is correct. It certainly makes sense for
>> libc to use it in targets that have it, assuming it safely produces
>> correct results, and for compilers to generate it in place of a call
>> to sqrt.
>>
>
> But again, that requires the appropriate flags.gcc/config/rs6000/rs6000-cpus.def:35:
>
>>> Also, at least according to Apple, which were the only ones actually
>>> looking at the thing, such as I could find, it was only ever supported
>>> by the 970 and the 970FX cores, released in 2002 and 2004, respectively.
>>> I highly doubt they'll have much relevance. Chalk up my suspicions from
>>> the OP to not having researched enough.
>>
>> Do you mean these are the only non-POWER line models that have fsqrt?
>>
>
> The more I research this, the more confused I get!
>
> So, I was looking for real-world users of fsqrt, do look at how they
> determine availability. The first such user I found was Apple's libm.
> Tracing back to where they set their feature flags, I found this file
>
> http://opensource.apple.com/source/xnu/xnu-1456.1.26/osfmk/ppc/start.s
>
> If you search for _cpu_capabilities, around line 180 you'll find a
> comment saying the feature flags in this file are only defaults and may
> be changed by initialization code. But I couldn't find anything setting
> more flags, if anything, flags got removed. And the only models that
> have the flag kHasFsqrt are the 970 and the 970FX.
>
> But then I noticed that their processor list is kind of small, so I
> continued the search. I found this e-mail claiming the 604 supports the
> instruction:
>
> http://aps.anl.gov/epics/tech-talk/2011/msg01247.php
>
> But if you look at datasheets of the 604, they say nothing either way.
> But alright, the 604 is and old model (intrduced in 1994), maybe fsqrt
> wasn't defined then.
>
> I personally work with the e300 (at my day job), and at least their
> datasheet makes it clear that fsqrt is not supported. Actually,
> apparently Freescale aren't big fans of this instruction at all,
> according to this comment:
>
> https://github.com/ibmruntimes/v8ppc/issues/119#issuecomment-72705975
>
> Wikipedia claims, however, that it wasn't until the 620 that the square
> root instruction was put into hardware. I tried to find a 620 datasheet,
> but no luck so far.
>
> Next family on the list would be the 4xx. 403 can be discounted
> immediately as it lacks an FPU. Since the 401 is stripped down even
> further, it also has no FPU. From the 405 onward it get's dicey as they
> went the way of the x87: You could connect an external FPU if desired.
>
> I found one for 405 here:
>
> http://www.xilinx.com/support/documentation/ip_documentation/apu_fpu.pdf
>
> That one doesn't support fsqrt, at least not enough for our purposes,
> but it does support fsqrts (that's the single precision variant). That's
> a whole new level of weird.
>
> As for the rest: I hope, Apple got it right, because afer the 970,
> nothing more is listed in Wikipedia.
>
> So, as you can see, the whole thing is a mess.
Since kernel does not track it, I found GCC internal implementation to
be the most correct way to found if an chip implementation actually
support some ppc instruction.
For fsqrt gcc will define _ARCH_PPCSQ and internally this flag is
controlled by OPTION_MASK_PPC_GPOPT. GCC cpu definition file has some
information about it [1]:
27 /* For ISA 2.05, do not add MFPGPR, since it isn't in ISA 2.06, and don't add
28 ALTIVEC, since in general it isn't a win on power6. In ISA 2.04, fsel,
29 fre, fsqrt, etc. were no longer documented as optional. Group masks by
30 server and embedded. */
31 #define ISA_2_5_MASKS_EMBEDDED (ISA_2_4_MASKS \
32 | OPTION_MASK_CMPB \
33 | OPTION_MASK_RECIP_PRECISION \
34 | OPTION_MASK_PPC_GFXOPT \
35 | OPTION_MASK_PPC_GPOPT)
36
36
37 #define ISA_2_5_MASKS_SERVER (ISA_2_5_MASKS_EMBEDDED | OPTION_MASK_DFP)
Later in the file you can check that besides all POWER chips from power4 and
forward, only the 970, cell, and G5 support fsqrt.
The problem is you have new powerpc cores as e6500 that is suppose to follow
the ISA 2.06 embedded profile but that does not implement fsqrt even on ppc64
mode.
[1] gcc/config/rs6000/rs6000-cpus.def
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
