Hi Jim, > I've started using some new gcc-4.6 options, > by adding these lines to coreutils' configure.ac: > > + gl_WARN_ADD([-Wsuggest-attribute=const]) > + gl_WARN_ADD([-Wsuggest-attribute=pure]) > + gl_WARN_ADD([-Wsuggest-attribute=noreturn]) > > I've already adjusted all of coreutils, but wanted to fix > gnulib first
How many percent of speed can you gain by doing this? I mean, 'const' and 'pure' optimizations can be very useful in numeric code, especially once you have derivatives, e.g. f(x) = 2*sin(x)*cos(x)^3 f'(x) = 2*sin(x)*3*cos(x)^2*-sin(x) + 2*cos(x)*cos(x)^3 But in code like gnulib or coreutils, where common subexpressions have been extracted from loops by hand already, you gain no more performance. So I think this is just a waste of time. I would think that <http://lists.gnu.org/archive/html/bug-gnulib/2011-04/msg00232.html> is higher priority. I have been able to get speedups of more than 5% by judiciously placing 'inline' keywords before function definitions. I think that's much more promising than providing the attributes 'pure' and 'const'. > It seems wrong to have to define these > > __attribute__ > _GL_ATTRIBUTE_PURE > _GL_ATTRIBUTE_CONST > > in every compilation unit that uses these attributes. We shouldn't define __attribute__ [1], and fortunately your patch does not do it. _GL_ATTRIBUTE_PURE and _GL_ATTRIBUTE_CONST could be defined through gnulib-common.m4, that's fine with me. Bruno [1] http://lists.gnu.org/archive/html/bug-gnulib/2011-02/msg00165.html -- In memoriam Nikolay Gikalo <http://en.wikipedia.org/wiki/Nikolay_Gikalo>