Rely on compiler to remove unused code or #ifdef out?

Question

I am working on a USB stack in C. This stack will be open source and used in various different projects.

Various configuration options are available, which enable or disable large chunks of code and constant data structures. As this is an embedded project it is important to minimize the footprint of the stack, and one of the benefits of disabling unused features is a reduction in flash and RAM use.

There are two ways to remove unused code from the build process output. Using #ifdef preprocessor directives causes the compiler to not even consider the unusued code. The main disadvantages are polluting the code with lots of #ifdefs and the potential to break disabled code and not get a compiler warning/error.

The other option is to include the code but allow the linker to eventually remove it. GCC is very good at this, and the resulting output is the same size as if it was removed with #ifdef. The down side to this is that it requires at least a minimum level of optimization to be enabled (-O1, functions in sections and unused section removal) and this behaviour isn't guaranteed on other compilers, or even other versions of GCC.

What is the best practice here and why? What are the advantages and disadvantages I have not considered?

Answer 1

Go for preprocessor directives. They shouldn't pollute too much the code (if they do, you can probably refactor those sections and extract them to a separate, possibly inlined, function, increasing its maintainability).

In my opinion, the most important point is that you can't know whether that section of code will actually be used or not. Today's modern IDEs can highlight or dim those sections depending on the configuration you're building to, when inside an #if...#endif block. This makes that code more maintainable and easy to identify. Relying solely on the compiler/optimizer will make that clear just to itself, with no practical advantage in terms of efficiency, performance, or program size.

Answer 2

Optimizing by removing unused code is one of the oldest optimizations out there. Remember computers used to have much fewer resources. Many of today's embedded platforms have more resources than desktops 30 years ago. If your embedded toolchain doesn't remove unused code, it's frankly a piece of junk.

#ifdefs are hard to read and hard to maintain. You are never going to keep up as well as pretty much any compiler written in the last 40 years that isn't an undergrad class project.

Answer 3

I believe the correct answer to "#ifdef or linker optimization" is YES.

I would use #ifdef around large, major parts that might not be utilized (for example, USB 3.0 support-specific code) to permit the developer to perform a "rough trimming" of the final object themselves, then let the linker perform the final optimization.

This has the benefit of giving some control to the developer for code-space optimization at the large-scale while not requiring them to use high-level optimization in the linker stage if they don't want to (remember, high-level optimization can refactor the code so much that when single-stepping in a debugger what the assembly/machine code is doing has very little resemblance on the C code as written).

Answer 4

"This stack will be open source"

conflicts with

"this behaviour isn't guaranteed on other compilers, or even other versions of GCC."

If other people build the source you can't rely on them using your approved compiler.

Say I use your project but for whatever reason i have to use a compiler which doesn't optimise the code so well.

I will be forced to fork your project, add the #ifdef statements and publish it as 'USBStackProject_ForOldCompilers' or something.

If you were distributing the binaries I don't think it would matter how you produced them. But you should make the code you distribute work with as many compilers as is reasonable.