Re: Optimizing empty functions in C

"Andrzej Wasowski" <wasowski@data.pl> wrote in message
> Will two identical functions generate the same code twice?


Generally, yes. Too much analysis for too little gain. If the
function is not static, or if it contains static local variables, you
can pretty much guarantee it.


> special case of this problem is most interesting for me: if I put many
> empty functions of the same time (let's say void f(void)) in my code -
> will I get many empty functions generated, just one of them, or
> perhaps none (because the compiler can eliminate the call alread)?


Generally, you will get everything. Some compilers will elimintate dead
code (i.e. Kuck C++ compiler - acquired by Intel a few years ago), but
usually only for static functions. Another possibility is to generate C++
and declare these functions inline. Note however that inline is just a
hint, and worst case you can get code-space explosion.


> what if the function is potentially called via function pointer? (I
> belive it is non-trivial to eliminate the call then).


Yes, because the pointer can come from anywhere. If you are using function
pointers, forget about the suggestion above of using inline - the compiler
will ignore inline in this case.


> Last but not the list: what would be normally faster to execute:
>
> a call to an empty function or a check of integer flag (check if there
> is any function to call), sthg like"
>
> if non_empty_f then f(); /* if f is empty */


Depends on your "hit" rate, the processor (mostly), and the compiler (a
little).


If the condition is always true, then the "if" is pure overhead and is not
worth doing. On the other hand if the condition is true only 10% of the
time, it may be worth doing.


On a typical risc processor, evaluating an if and calling a function take
about the same amount of time, so you should just call the function. On
intel, function calls take a lot longer, so it is probably worth evaluating
the if.


The only way to figure out what works best is to write some test code and
try it on potential target compilers.


--
Scott Nicol
snicol@apk.net

Return to the comp.compilers page.
Search the comp.compilers archives again.