Hi Kevin Long, > b) in the /*do something*/ block, we may use a.push_back(...) or some other > functions > that can change the size of a. if this happen, of course we can not do the > optimization. Correct. > so can gcc know what functions may change the size of a? Yes, if GCC has sufficient information to guarantee that the size of a is not being changed it can perform the LIM optimization and hoist the a.size() method out of the routine. Note: a.size() can be hoisted out because it is an inline function. > is gcc smart enough to optimize the code if those functions are not used? Yes. > i am sorry because i am not familiar with the optimization term. Move loop invariant optimization. Or loop invariant motion optimization. Usually abbreviated LIM. > a) we tell the gcc what function may change the size of a vector And most C++ compilers accomplish that at a "veneer" level (versus a "holistic" level). By the heavy use of inline functions to expose (and inject) the innards of the methods into the location, "as if" the body of the routines were typed in place. Small inline functions optimize very well, and the optimizer has enough information to perform LIM optimizations. Especially for leaf-loops (loops that do not call any non-inline functions within the loop). NOTE: I'm assuming correct code. Incorrect code (what I tend to call "pathological code") can cause unexpected behavior. For example, if the code violates aliasing rules, all bets are off. > b) in the internal of gcc, gcc can find them out That's a holistic optimization. The kind that the LLVM compiler performs, or the Java JIT optimizer performs. > which one is more reasonble? or none of them? They are both reasonable. I expect the holistic optimization is tricky to implement, and requires significant infrastructure to support at the object code and library levels. Sincerely, --Eljay
