[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 27 Feb 2019 12:26:41 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: FE Exception triggered by comparison
On Wed, Feb 27, 2019 at 08:14:07PM +0300, Alexander Monakov wrote:
>
>
> On Wed, 27 Feb 2019, Rich Felker wrote:
>
> > Are there reasons we should perhaps use the __builtin versions of
> > these when __GNUC__ indicates they're available? I like our bit test
> > versions we have now, and I think they're sufficiently efficient, but
> > I'm open to changes if there's a good reason.
>
> Well, it really depends on what one considers 'sufficiently efficient'.
> Instead of comparing a register with itself and testing flags (2 instructions)
> you get (for 'int f(double x){return isnan(x);}'):
>
> f:
> movabsq $9223372036854775807, %rdx
> movq %xmm0, %rax
> andq %rdx, %rax
> movabsq $9218868437227405312, %rdx
> cmpq %rdx, %rax
> seta %al
> movzbl %al, %eax
> ret
>
> (note that movq %xmm0, %rax is going to be more costly than a normal
> move as it crosses from fp to integer domain in the cpu)
>
> I think musl bit test can be implemented more efficiently via right-shifting
> the representation in %rax first, avoiding 64-bit immediates,
Or left-shifting rather than masking to get rid of the sign bit?
That's all it's doing. I don't think right-shift is okay since losing
any low bits would break the comparison.
> but even then
> I'd say the "native" version is preferable.
I suspect this is probably true, though I also worry a bit whether
there are archs where it does something inefficient or broken.
Ideally the compiler would be able to recognize portable (within IEEE)
patterns for floating point representation examination and optimize
them if there's a more efficient way to be able to do it for a
particular machine.
Rich
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.
