a question about code optimization

[John Love-Jensen]

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