C语言编程。 为什么函数指针会破坏优化

Question

I've had a love/hate relationship with C programming with function pointers. I mainly work with microcontrollers where flash space is limited, so obviously I take a strong interest in using optimizations. One the one hand, function pointers make my life SO easy as I can write a hardware-portable software module in which the user can provide function callbacks for doing hardware-dependent things (ex: User callback to write byte to a serial port). In this way, I can write code that is 95% platform independent and then it's a quick job to port to new hardware.

On the other hand, I have noticed that a lot of compilers throw optimizations out the window when they see any use of function pointers. For example, I wrote a fairly generic function that accepts an enumerated type as an argument and then has a giant switch/case statement for each enumerated type selection to configure registers and such, depending on which enumerated type the user passed into the function.I'm calling this function once with a constant literal, IE something that should never change. The built binary seems to be including op codes to handle every single switch/case selection, even though all but one of the case selections should be deemed "dead code." I played with the different optimization settings, but to get the smallest binary I had to completely comment out every "case" block except the one I needed, and this reduced by flash utilization by about 1k bytes. If I don't use function pointers, it has no problem optimizing this code.

The strange part is that I have never utilized a function pointer in my code with that function's prototype. And for the function pointer prototypes I had used, the pointer was established once at startup to a static function and then never again (another constant literal assignment). I know I could probably accomplish the same design goals using #defines all over the place, but it irks me that the tools can't interpret what is possible/impossible based on my code.

I can see the case where you have a function pointer, and some dynamic thing that you can't predict for executes the function (ie a person types into a terminal and you don't know in advanced what the arguments will be).

Is there any good reason why compilers struggle to optimize when function pointers are used, even in a predictable way?

Answer 1

Without seeing your code, I can't draw any definitive conclusions, but here is what I know from my own experience.

Even if the function is static and only called once, the pointers are being initalised at runtime. The compiler can't optimise away function pointers whose addresses are not known until runtime.

It also can't optimise away function pointers when the functions exist in other translation units; it doesn't know where functions are if they're outside the translation unit, only that they've been declared; it's the linker's job to handle that. I believe it should be theoretically possible for LTO to handle this, but I'm not sure if any implementations do so.

However, some compilers can optimise function pointers (MSVC comes to mind) if it knows where all the addresses are, and if the function pointers are initalised at compile-time.

Answer 2

The basic problem is separate compilation -- when you have a language (such as C) where different source files are compiled separately and later linked together by a separate linker, the compiler optimizer doesn't know about anything that is in other compilation units when it runs (those compilation units might not even have been written yet!), so it has no way of knowing that the pointer is not modified and/or the function is not called with any other argument.

One possible solution to this is link-time optimization -- if your development suite supports it.

Another is forcing everything into one compilation unit and making everything static so that the compiler knows no other compilation unit can refer to it. This may allow the optimizer to do a better job.