使用gcc与glibc来优化程序 转载.docVIP

使用gcc和glibc来优化程序 转载 使用gcc和glibc来优化程序(转载)2011-01-12 17：38Optimize Applications with gcc and glibc by Ulrich Drepper 1.介绍 === 本文总结一些关于代码优化的经验,这些经验是不完整的. 本文不是讨论编译器如何优化代码,后者是完全不同的另外一个领域. 2.编译时优化(Using Optimizations Performed at Compile-Time) ===== 2.1消除无用代码(Dead Code Elimination) Dead Code指永远不会执行的代码. 例如： long int add(long int a,void*ptr,int type) { if(type==0) return a+*(int*)ptr； else return a+*(long int*)ptr； } 这个函数根据type的值来判断ptr的类型,从而求和. 优化1：多数情况下int和long int是相同的,因此可以优化为 long int add(long int a,void*ptr,int type) { if(sizeof(int)==sizeof(long int)||(type==0)) return a+*(int*)ptr； else return a+*(long int*)ptr； } sizeof运算总是在编译时进行,因此增加的条件表达式总是在编译时计算. 如果long int和int确实相同,那么这个函数就可以被编译器优化. 进一步优化,利用limits.h中定义的宏 #include limits.h long int add(long int a,void*ptr,int type) { #if LONG_MAX！=INT_MAX if(type==0) return a+*(int*)ptr； else #endif return a+*(long int*)ptr； } 这样,即便在long int不同于int的平台上,该函数也被优化了 2.2节省函数调用(Saving Function Calls) 很多函数很短小,相对函数执行的时间,函数调用的代价不可忽视.例如 标准库中的字符串函数和数学函数.解决办法有两个：使用宏代替函数, 或者用inline函数. 一般而言,inline函数和宏一样快,但是更安全.但是如果用到alloca和 __builtin_constant_p的时候,可能要考虑用优先使用宏了 但是,如果函数被声明为extern,inline并不总是有效了.另外,当gcc的 编译优化选项没有打开时,gcc不会展开inline函数. 如果inline函数是static的,那么编译器总是会展开该函数,不考虑是否 真的值得.尤其是当使用-Os(optimize for space)选项时,static inline函数是否值得使用就是个问题了. 编写正确而又安全的宏并不容易.要注意 a)正确使用括号括起参数, 例如 #define mult(a,b)(a*b)//错误 #define mult(a,b)((a)*(b)) b)宏定义中的大括号引入新的block,这有时侯会导致问题. 例如 #define scale(result,a,b,c)\ {\ int c__=(c)；\ *(result)=(a)*c__+(b)*c__；\ } 下面的代码编译会出现问题： if(.) scale(r,a,b,c)；///多余的分号导致编译错误else else { } 正确的写法应该是： #define scale(result,a,b,c)\ do{\ int c__=(c)；\ *(result)=(a)*c__+(b)*c__；\ }while(0) c)如果参数是表达式并且在宏定义中出现多次,尽量避免重复计算. 这也是上面例子中要引入变量c__的原因.但这会限制变量c__的类型. d)宏缺乏返回值 2.3编译器内部函数(Compiler Intrinsics) 绝大部分C编译器都知道内部函数(Intrinsic functions).它们是特殊的 inline函数,由编译器提供使用.这些函数用外部实现来代替. gcc2.96的内部函数有 *__builtin_alloca：动态分配栈上内存 dynamiclly allocate memory on the stack *__builtin_ffs： find first bit set *__builtin_abs,__builtin_labs： absolute value of an integer *__builtin_