[PATCH] math: remove exp10 wrappers

[Adhemerval Zanella Netto]

On 16/01/24 13:08, Szabolcs Nagy wrote:
> The 01/16/2024 15:41, Wilco Dijkstra wrote:
>> Hi Adhemerval,
>>
>>> The patch below fixes the numerical stability I found on i686:
>>
>> So it looks like it is due to incorrect uses of math_narrow_eval with
>> double_t expressions: kd = math_narrow_eval (z + Shift);
>> This needs to be: kd = math_narrow_eval ((double) (z + Shift));
>>
>>> And I think we haven't see it because all ABIs with FLT_EVAL_METHOD=2 uses
>>> assembly implementations for exp/exp2/exp10 (this is the case for i386
>>> and m68k).
>>
>> Indeed.
>>
>>> Furthermore, at least with i686 the use of double_t also does not show
>>> better performance either. The current sysdeps/i386/fpu/e_exp10.S
>>> on a recent CPU (Ryzen 9 5900X) with gcc version 13.2.1:
>>
>> That's surprising. What happens is that we build with -std=gnu11 which implies
>> -fexcess-precision=fast. I double-checked on a SkyLake - using double_t is slower
>> as well. So overall it seems best to let the compiler decide where to use excess
>> precision.
>>
>>> So I am not sure if double_t is really helpful here.
>>
>> Unless we decide to move to -fexcess-precision=standard by default I guess -
>> but there doesn't seem to be an advantage in doing so given that double_t
>> is slower.
> 
> the code was written with standard conformance in mind.
> (i.e. it should have reliable semantics with any iso c
> compiler.)
> 
> glibc does not build in standard confrom excess precision
> mode, so i was using float_t and double_t to avoid changing
> semantics depending on cflags. (the narrow eval issue was
> an oversight that can be fixed with a cast.)
> 
> i did not expect double ops with non-standard excess
> precision handling to have different performance than long
> double ops on i386.
> 
> if that's the case then indeed using float/double directly
> may be better than float_t/double_t (but keep in mind if
> somebody builds the code outside the glibc tree to do
> tests or other analysis the behaviour will be fragile on
> targets like i386 and m68k. same if we ever want to change
> the glibc build flags to iso c mode on those targets.)

My plan is to send some fixes to allow remove some remaining assembly
implementations from i386.  I don't think it would worth to change
the current code besides the numerical stability I have found.