This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug math/15384] One constant fewer in ieee754/dbl-64/wordsize-64/s_finite.c
- From: "marc.glisse at normalesup dot org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Sun, 21 Apr 2013 18:06:44 +0000
- Subject: [Bug math/15384] One constant fewer in ieee754/dbl-64/wordsize-64/s_finite.c
- Auto-submitted: auto-generated
- References: <bug-15384-131 at http dot sourceware dot org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=15384
--- Comment #8 from Marc Glisse <marc.glisse at normalesup dot org> 2013-04-21 18:06:44 UTC ---
(In reply to comment #7)
> Performance of noninlined function does not make lot of sense because gcc
> inlines them all.
I thought for glibc it did make sense, since the glibc functions won't be
inlined. Now optimizing the gcc builtins is a different story, those are always
inlined (and there you also want to check how well the expansion interacts with
the vectorizer).
> This was partly reason I optimize for size.
That makes sense.
> As I bet that 99% of use cases are something like
> if (isfinite(x)) stuff() else error();
> I added benchmark for testing a branch. Then my modified versions seem to win.
> on nehalem
>
> Last implementation correctly computed 1 for infinite values and 0 otherwise.
finite7 from your "benchmark for inlines" is giving me a different answer for
1.0 and 2.0. I would understand it better with 0x7ff instead of 127.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.