This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Optimization comparison: 3.3, 3.4, mainline, tree-ssa
- From: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>
- To: gcc at gcc dot gnu dot org, uros at kss-loka dot si
- Date: Mon, 19 Apr 2004 08:02:47 -0400 (EDT)
- Subject: Re: Optimization comparison: 3.3, 3.4, mainline, tree-ssa
- References: <40837167.5000902@kss-loka.si>
> From: Uros Bizjak <uros@kss-loka.si>
>
> 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.
Well glibc already provides inline implementations via mathinline.h.
The problem is we don't have a way of selectively turning off certain
math inlines and not others. As my figures showed, even with the
blunt instrument of turning all of them off, I get 30% better speed.
We'd get more speedup if you could put the other opts into the .md
file also. (Hack hack, measure, measure) it becomes a 36.5%
improvement judging by adding just inline asin and fmod to almabench.
--Kaveh
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu