[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 23 Feb 2020 19:14:08 +0300 (MSK)
From: Alexander Monakov <amonakov@...ras.ru>
To: musl@...ts.openwall.com
Subject: Re: Q: dealing with missing removal of excess precision
On Sat, 22 Feb 2020, Rich Felker wrote:
> I'm not well acquainted with SSE, and only so-so with x87, so pretty
> much I'm reading them for higher-level issues with tooling
> compatibility (like the concerns I already raised and looked up and
> seem to have resolved about x87 constraints and non-GCC compilers) and
> logic, then planning to apply and test them. I think being aware of
> non-obvious mistake modes that have already been found would be a lot
> more useful than staring at things, especially if the bugs you've
> found are in subtleties of the insn behavior or constraint behavior.
Okay, thanks. I found two issues:
1. i386 lrint* functions mistakenly used fistpll instead of fistpl (I
posted the fix for x32 asm after noticing my own mistake).
2. Some functions bind a 32-bit lvalue as output for fnstsw %ax, which
as the operand says writes only 16 bits. They should be changed to either
use a 16-bit lvalue, or a zero-initialized 32-bit lvalue with "+a" constraint.
Plus, not bugs, but still worth mentioning:
3. The new remquol in C could alternatively be implemented by using fxam
to extract sign bits instead of loading them from stack slots. The current
approach makes sense given the ABI, but an implementation aiming for better
code after inlining could choose to use fxam instead of forcing a spill.
4. I did not manage to find a copy of Figueroa's "When is double rounding
innocuous", but I could cite e.g. "Innocuous Double Rounding of Basic
Arithmetic Operations" by Pierre Roux instead (in i386/sqrtf.c).
If you like you can fetch a Git tree with my patches from
https://git.sr.ht/~amonakov/musl
(issue 1 is already corrected in that repo)
Thanks.
Alexander
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.
