Updating glibc mathinlines.h to reflect additional GCC builtins ?

[Uros Bizjak]

Kaveh R. Ghazi wrote:

>Looking through mathinline.h and cross referencing it with gcc, I
>think the following additional builtins might be usable:
>
>pow2 (-> __builtin_exp2 ?)
>sincos (?)
>floor
>ceil
>rint
>
>(Uros, does this match what you implemented in GCC in the last few
> months?  Have I missed any?)
>  
>
nearbyint() is also implemented as builtin.

Regarding sincos(), a patch was submitted to gcc-patches 
(http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00555.html). It used 
soon-to-be-obsoleted ADDRESSOF optimization in sincos expander 
(http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00653.html), so it was not 
commited to CVS. As fsincos is generated automatically, it was somehow 
put on hold...

>ldexp
>  
>
ldexp needs an expander and perhaps an expand_twoval_unop() which would 
handle (double),(int) combination.
frexp also needs the same expander, but as in sincos case, without 
ADDRESSOF optimization.

>fma
>hypot
>  
>
fma and hypot were discussed in length here: 
http://gcc.gnu.org/ml/gcc-patches/2004-05/msg00385.html. However, they 
could stay  as inline function (explanation is below).

>lrint
>llrint
>  
>
The patterns to implement this function would be actually the same as 
patterns to implement fix_trunc* insn. With current infrastructure, the 
only difference from fix_trunc* for x86 would be an  (set_attr "i387_cw" 
"any") instead of  (set_attr "i387_cw" "trunc"). However, whole block of 
fix_trunc* patterns would have to be copied - perhaps this could be 
implemented with more elegance by using new macro stuff?

OTOH, infrastructure allows us to implement BUILT_IN_LCEIL, 
BUILT_IN_LLCEIL, BUILT_IN_LFLOOR, etc... to optimize an `(int) floor()` 
construct. Again just by changing a value of "i387_cw" attribute. Of 
course, some help from midlevel would be needed to transform (int) 
floor() into BUILT_IN_LFLOOR, just like (int) rint() is transformed into 
BUILT_IN_LRINT. And SSE instructions could be plugged into this scheme - 
by adding "sse_*" values (with appropriate control word handling) to 
i387_cw attribute [well, we shouldn't call it i387_cw in this case ;> ]. 
Unfortunatelly, this is 4.1 stuff...

Regarding hyperbolic functions (and perhaps fma and hypot): they are 
implemented as ordinary math on "leaf" functions, and RTL optimizers 
optimize these as if they were written in the form of RTL patterns. I 
think that these functions should remain in their current form as 
inlined functions. However, sgn/sgn1 should be implemented as "leaf" RTL 
pattern for them.

Basically, everything is already implemented, just some "glue logic" is 
missing.

Uros.