Optimization comparison: 3.3, 3.4, mainline, tree-ssa

[Uros Bizjak]

Hello!

>Strange.  Using last night's mainline on i686-pc-linux-gnu, when I
>supply either -D__NO_INLINE__ or -D__NO_MATH_INLINES I get a dramatic
>30% speedup for alma.  Still not as fast as ICC, but better than it
>was.  I suspect we'll do better when Uros finishes the x87
>instrinsics. :-)
>http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00863.html
>
The problem with this approach is, that with -D__NO_INLINE__, asin() and 
drem()functions, which are part of almabench, still produce a call to 
math library. These functions are currently not implemented as intrinsic 
functions ( http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00876.html ).

I would like to ask, if these (somehow complex) functions should be 
implemented as inline functions in a compiler provided optimized header, 
or as intrinsic functions. For example, asin() and acos() doesn't have 
hardware implementation, and because of this,  I would suggest 
implementing them as inline functions. The same goes for asinh, acosh, 
etc... which are even more complex function, and I see no point to 
implement them in *.md file.
For example, asin() function, implemented with atan2 from previous mail, 
produce with '-O2 -ffast-math -fomit-frame-pointer' this asm:

asin:
        fldl    4(%esp)
        fld     %st(0)
        fmul    %st(1), %st
        fsubrl  .LC1
        fsqrt
        fpatan
        ret

BTW: I would really appreciate some help with -rint(), lrint() and 
llrint() builtins 
http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00876.html , especially 
with rounding issues...

Perhaps gcc can get some performance gain from fpregparm patch (still 
unreviewed, http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00772.html ).

    Uros.