[PATCH] math: Remove fenvinline.h

Adhemerval Zanella adhemerval.zanella@linaro.org
Fri Mar 6 18:47:00 GMT 2020



On 06/03/2020 15:08, Tulio Magno Quites Machado Filho wrote:
> Adhemerval Zanella <adhemerval.zanella@linaro.org> writes:
> 
>> Similar to string2.h (18b10de7ce) and string3.h (09a596cc2c) this
>> patch removes the fenvinline.h on all architectures.  Currently
>> only powerpc implements some optimization.
>>
>> As for the strings optimization, this kind of optimization is
>> better implemented by the compiler (which handles the architecture
>> ISA transparently).
>>
>> Also, for the specific optimized powerpc implementation the code is
>> becoming convoluted and these micro-optimization are hardly wildly
>> used, even more being a possible hotspot in realword cases
>> (non-default rounding are used only on specific cases and exception
>> handling are done most likely only on errors path).  The fact
>> that no other architecture bother to implement such optimization
>> is also an indication that these should no be on libc.
>>
>> The math/test-fenv already covers all math/test-fenvinline tests,
>> so it is safe to remove it.
>>
>> Checked on x86_64-linux-gnu and powerpc64le-linux-gnu.
> 
> As has been mentioned in the previous thread [1]: I welcome this patch after the
> proposed compiler features are implemented, but I don't think glibc
> should remove fenvinline.h before that.
> 
> [1] https://www.sourceware.org/ml/libc-alpha/2020-03/msg00073.html
> 

Any real program actually benefits from this optimization, meaning
that fegetround/feraiseexcept/feclearexcept is being a hotspot? 
Also, why not adding other fenv functions, such as fetsetround
(since it the program is probing the rounding more, it most likely
want to set to a non-default)? 

Also, g++ disable such optimization on 
libstdc++-v3/include/c_compatibility/fenv.h, since it is not 
compatible with C++ (which is another indication that is really
does not make sense to continue exporting it).

The change of gcc is orthogonal to this one and I would like to
not encourage other ports to push for such optimization on glibc.



More information about the Libc-alpha mailing list