[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 6 Aug 2021 10:27:02 -0400
From: Rich Felker <dalias@...c.org>
To: Stefan Kanthak <stefan.kanthak@...go.de>
Cc: Alexander Monakov <amonakov@...ras.ru>, Szabolcs Nagy <nsz@...t70.net>,
musl@...ts.openwall.com
Subject: Re: [Patch] src/math/i386/remquo.s: remove conditional
branch, shorter bit twiddling
On Fri, Aug 06, 2021 at 12:17:12PM +0200, Stefan Kanthak wrote:
> Alexander Monakov <amonakov@...ras.ru> wrote:
>
> > On Wed, 4 Aug 2021, Stefan Kanthak wrote:
> >> The change just follows by removing 6 LOC/instructions.-)
> >
> > Have you considered collecting the three bits in one go via a multiplication?
>
> No. My mind is not that twisted;-)
>
> > You can first isolate the necessary bits with 'and $0x4300, %eax', then do
> > 'imul $0x910000, %eax, %eax' to put the required bits in EAX[31:29] in the
> > right order, then shift right by 29. Three instructions, 14 bytes.
>
> Thanks, VERY NICE! How did you come up to it?
>
> Revised patch with shorter bit twiddling attached.
The path forward for all the math asm is moving it to inline asm in C
files, with no flow control or bit/register shuffling in the asm, only
using asm for the single instructions. See how Alexander Monakov did
x86_64 remquol in commit 19f870c3a68a959c7c6ef1de12086ac908920e5e. I
haven't read the mul trick here in detail but I believe it should be
duplicable with plain C * operator.
I really do not want to review/merge asm changes that keep this kind
of complex logic in asm when there's no strong motivation for it (like
fixing an actual bug, vs just reducing size or improving speed). The
risk to reward ratio is just not reasonable.
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.
