On 8/14/25 3:48 PM, Vineet Gupta wrote:
So I'm guessing the issue at hand is in that rounding path that does not
use Zfa we've introduced a flt instruction where we didn't have one
before (previously we likey called into glibc).
No flt exists even in glibc - it just happens after NaN check (look at the
snippet above which is mor eor less same for both cases)
Sorry, should have been clearer. When calling into glibc, glibc will
ensure that the FP state is only changed in ways specified by the
appropriate standards.
And so now we have to
manage the accrued exception state? Essentially saving/restoring state
around the round() case?
glibc already saves/restores arounf ftl which gcc code doesn't - which is the
bug.
Understood. I actually think we're in agreement here.
My recollection is that sequence was dramatically better than what we
had before, so even with a bit mucking around with FP CSRs it's likely
still profitable.
For !zfa gcc is slightly worse off as the flag restore happens unconditionally
vs. glibc not doing this for NaN, granted we don't want to optimize that.
So we will be at par with glibc, not better. The better off was with zfa AFAIKR.
I was pretty sure the non-Zfa path was a significant improvement over
calling into the library and the Zfa path was further improvement as
well. That may be less now, but even avoiding the call overhead and
such for something like round() is useful.
It failed CI, presumably a scan test:
https://github.com/ewlu/gcc-precommit-ci/issues/3774#issuecomment-3188777455
Assuming the scan test just needs the count updated, this is OK for the
trunk.
Yes it needed adjustment due to additional save/restore. Fixed that and will
push shortly.
Sounds good and thanks for clarifying.
jeff
