Re: [PATCH v2] Enable inlining issignalingf within glibc

[Paul Clarke <pc at us dot ibm dot com>]

On 10/29/19 5:18 PM, Joseph Myers wrote:
> On Mon, 30 Sep 2019, Paul A. Clarke wrote:
>> issignalingf is a very small function used in some areas where
>> better performance (and smaller code) might be helpful.
>>
>> Create inline implementation for issignalingf.
>>
>> 2019-09-30  Paul A. Clarke  <pc@us.ibm.com>
>>
>> 	* sysdeps/generic/math_private.h (GET_FLOAT_WORD, SET_FLOAT_WORD):
>> 	Moved...
>> 	* include/math.h (GET_FLOAT_WORD, SET_FLOAT_WORD): to here.
>> 	(__issignalingf): New, copied from
>> 	sysdeps/iee754/flt-32/s_issignalingf.c.
> 
> This is OK.
> 
> There's the question of what to do about issignalingf_inline in 
> sysdeps/ieee754/flt-32/math_config.h and its uses in 
> sysdeps/ieee754/flt-32/e_powf.c.  Arguably they ought to move to just 
> calling issignaling.  If however the slightly different code in 
> issignalingf_inline results in better code in the callers (which would 
> need to be checked, I don't know whether masking or shifting would be 
> better in general), that would indicate (a) changing the code in the 
> generic inline and (b) filing a GCC bug report to convert one into the 
> other as an optimization.
> 

The generated code was identical on ppc64le.  There were a few minor differences on x86_64 (GCC7 and GCC8; looking at just the mnemonics; '-' is current issignalingf_inline, '+' is new __issignalingf):
--
@@ -210,7 +210,7 @@
 xor    
 movss  
 
-add    
+and    
 cmp    
 jbe    
 mov    
@@ -244,10 +244,9 @@
 movaps 
 retq   
 xor    
-lea    
+and    
 cmp    
 ja     
 movss  
---

...but I am far from an expert as to which is better on x86_64.

PC