This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


 > 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]