[PATCH v2 0/5] math: Optimize frexp functions with fast path

[Osama Abdelkader]

On Tue, Nov 04, 2025 at 05:48:26PM +0100, Adhemerval Zanella Netto wrote:
> 
> 
> On 04/11/25 07:55, Osama Abdelkader wrote:
> > On Thu, Oct 23, 2025 at 06:06:26PM +0300, Osama Abdelkader wrote:
> >> This patch series optimizes the frexp family of functions by adding a fast
> >> path for normal floating-point numbers, which represent the vast majority of
> >> real-world usage.
> >>
> >> Changes in v2:
> >> - Use arithmetic approach instead of bit masking (better on ARM/RISC-V)
> >> - Removed ancient 1995 copyright and rcsid tags (significant rewrite)
> >> - Use stdc_leading_zeros for subnormal normalization (float/double)
> >> - Simplified zero/inf/NaN check to (int32_t)(hx << 1) <= 0
> >> - Added separate benchmark workloads for zero and denormal cases
> >> - All tests pass including subnormal edge cases
> >>
> >> The optimization uses a single unsigned comparison (ex - 1) < MAX_NORMAL_EXP
> >> to identify normal numbers and returns immediately via arithmetic on the bit
> >> representation, avoiding branches and complex operations.
> >>
> >> Benchmark results on Intel Core i9-13900H (13th Gen):
> >>
> >>   Function     Baseline    Optimized   Speedup    Workload Breakdown
> >>   --------     --------    ---------   -------    ------------------
> >>   frexp        6.778 ns    4.007 ns    1.69x      Zero: 3.58ns, Denormal: 6.10ns
> >>   frexpf       5.858 ns    4.003 ns    1.46x      Zero: 3.58ns, Denormal: 5.60ns
> >>   frexpl      25.543 ns   25.531 ns    1.00x      Zero: 17.8ns, Denormal: 23.9ns
> >>
> >> The optimization provides good improvements for float (31.7%) and double
> >> (40.9%) precision. All existing tests pass, maintaining exact correctness for
> >> edge cases including zero, subnormal, infinity, and NaN values.
> >>
> >> The arithmetic approach generates better code than bit masking on ARM (fused
> >> shift-subtract) and RISC-V (avoids loading large constants), as verified via
> >> godbolt compiler explorer.
> >>
> >> Suggested-by: Wilco Dijkstra <wilco.dijkstra@arm.com>
> >>
> >> Osama Abdelkader (5):
> >>   benchtests: Add benchmarks for frexp functions
> >>   math: Optimize frexpf (binary32) with fast path for normal numbers
> >>   math: Optimize frexp (binary64) with fast path for normal numbers
> >>   math: Optimize frexpl (intel96) with fast path for normal numbers
> >>   math: Optimize frexpl (binary128) with fast path for normal numbers
> >>
> >>  benchtests/Makefile                 |    6 +
> >>  benchtests/frexp-inputs             | 1013 ++++++++++++++++++++++++++
> >>  benchtests/frexpf-inputs            | 1013 ++++++++++++++++++++++++++
> >>  benchtests/frexpl-inputs            | 1014 +++++++++++++++++++++++++++
> >>  sysdeps/ieee754/dbl-64/s_frexp.c    |   55 +-
> >>  sysdeps/ieee754/flt-32/s_frexpf.c   |   82 ++-
> >>  sysdeps/ieee754/ldbl-128/s_frexpl.c |  100 +--
> >>  sysdeps/ieee754/ldbl-96/s_frexpl.c  |  101 +--
> >>  8 files changed, 3221 insertions(+), 163 deletions(-)
> >>  create mode 100644 benchtests/frexp-inputs
> >>  create mode 100644 benchtests/frexpf-inputs
> >>  create mode 100644 benchtests/frexpl-inputs
> >>
> >> -- 
> >> 2.43.0
> >>
> > 
> > Hi All,
> > 
> > I wanted to follow up on this patch series sent on Oct 23. I've addressed
> > the feedback from Wilco, Adhemerval, and Paul:
> > 
> > - ~ 40% performance improvement for double precision
> > - ~ 32% performance improvement for float
> > - Arithmetic approach (better on ARM/RISC-V per godbolt)
> > - All tests passing
> > 
> > Is there anything else needed for this to move forward?
> 
> Hi Osama,
> 
> I think the patches look good, just the benchmark one that I think
> you should just remove the zero and denormal inputs since they do
> not add much for performance optimization focus.
> 
> I will check the ldbl-96 version later, but I have checked the
> float, double, and long double on aarch64 and they seems ok and
> with better numbers as well.
> 
> > 
> > Thanks,
> > Osama
> 

Hi Adhemerval,

Thank you. will do that.
I can try same pattern to optimize scalbn as a next step, would that be ok?
Appreciate your feedback.

Thanks,
Osama