Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 15 Aug 2021 09:57:51 -0500 (CDT)
From: Ariadne Conill <>
To: Rich Felker <>
cc: Ariadne Conill <>,, 
    Szabolcs Nagy <>
Subject: Re: [PATCH #2] Properly simplified nextafter()


On Sun, 15 Aug 2021, Rich Felker wrote:

> On Sun, Aug 15, 2021 at 02:46:58AM -0500, Ariadne Conill wrote:
>> On Sun, 15 Aug 2021, Stefan Kanthak wrote:
>>> [stefan@...e ~]$ gcc --version
>>> gcc (GCC) 8.3.1 20190311 (Red Hat 8.3.1-3)
>>> Copyright (C) 2018 Free Software Foundation, Inc.
>>> This is free software; see the source for copying conditions.  There is NO
>> gcc 8 is quite old at this point.  gcc 9 and 10 have much better
>> optimizers that are much more capable.
>> Indeed, on my system with GCC 10.3.1, nextafter() is using SSE2
>> instructions on Alpine x86_64, and if I rebuild musl with
>> `-march=znver2` it uses AVX instructions for nextafter(), which
>> seems more than sufficiently optimized to me.
> As far as I can tell, the instructions used are not the issue here,
> and there are no specialized instructions that help make it faster. If
> GCC is doing a bad job, it's more a matter of the high level flow,
> choice of how to load constants, how branches are implemented, etc.

Right, I'm just more saying that at least from what I see at glancing at 
the disassembly in both cases, the code generated by GCC 10 does not seem 
particularly bad.

(And nitpicking in the aggressive way Stefan is doing over 3 nsec per call 
in something that really is not generally a fastpath is kind of silly 


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.