[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZfVjWK1HXj886Rx2@voyager>
Date: Sat, 16 Mar 2024 10:16:08 +0100
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: Re: x86 fma with run-time switch?
Am Sat, Mar 16, 2024 at 04:37:29AM +0100 schrieb Markus Wichmann:
> The problem with that idea is that CPUID returns an enormous amount of
> information, but right now we only care about two bits on x86_64 (namely
> FMA and FMA4 support). So we could have some internal word such as
> __cpuid, that basically contains a digest of the CPUID information,
> namely only the bits we care about. That would be extensible for up to
> 64 bits we want to look at, but it would require complex control flow.
> And I thought you were against complex control flow in assembler.
>
OK, I may have misunderstood for a moment here. The benefits of fourty
winks and a cup of joe, I suppose. But I am attaching an initial
proposal to this one, where the initialization is in C.
One problem that came to me while making the commits is that this is
raising the required ISA level of the assembler. And I don't really know
whether that is a problem. Dealing with it requires yet more work: We
would have to add a configure test, and then not emit the new
instructions if the assembler can't handle them. I don't think we will
be able to just emit these instructions as numbers while still using
named input and output constraints.
On the other hand, these instructions (and support for them) have been
around for one and a half decades by now, so it ought to be fine, right?
Ciao,
Markus
View attachment "0001-Add-internal-CPUID-machinery.patch" of type "text/x-diff" (3443 bytes)
View attachment "0002-Runtime-switch-hardware-fma-on-x86_64.patch" of type "text/x-diff" (2849 bytes)
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.
