Thread: mingw optimization question

Does mingw optimize multiplication/division by one? That is, if I write

Code:

ONE * a

or

Code:

a * ONE

or

Code:

a / ONE

, will it be optimized to just

Code:

a

? Here, ONE is either a define or a const that is set to one. Also, does it depend on whether a is a float type or not? If a is an integer, ONE is of course also an integer.

The reason I'm wondering is because I have many expressions that contain a variable that may or may not be set to one, depending on a compile time flag. If the expressions are not optimized when the variable is set to one, I would have to write two different versions of each expression, one for each value (0 or 1) of the flag, and optimize the expressions manually.

Just write the code and let the compiler sort it out.

Otherwise, you're just suffering from premature optimisation disease.

Generally, gcc (like a lot of other modern compilers) is able to optimise out such things, particularly at higher optimisation settings. I wouldn't bet on it happening for unoptimised compilation (or when compiling for debugging purposes).

Logically, however, I would wonder why a programmer would deliberately write code of the form "x = ONE * a" or "y = a/ONE" if you know that ONE expands, at compile time, to a numeric value 1. I am aware that sometimes one as expressions of the form "x = some_configurable_factor * a" or "y = a/some_configurable_factor" where some_configurable_factor is always a compile time constant, but may be configured to different values when building. But few folks who understand the english language would look at a name ONE and expect it to expand to (say) a value of 47.

You compile
gcc -S prog.c
to get prog.s

But you're just wasting your time IMO.

Until you have a finished program, which you can profile with real-world data, you're in no position to even guess where the performance bottlenecks are.

What you can do however is make sure you're using the most appropriate algorithms and data structures for the problem. Because there isn't a compiler out there that can fix the monumental screw-up of writing say bubble sort when the best thing to do would have been to use quicksort.

Leave the micro-optimisations and bit fiddling to the compiler (it's good at doing it, and will beat you every time). Focus on the big issues like choosing algorithms, and making sure the damn thing works (nobody will give a damn about your buggy program if it produces garbage, no matter how fast it is).