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.

It seems...(from a single trivial check of the asm output) that gcc does it.
But that may not be the case for more complicated code.

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.

Quote:

---

Originally Posted by grumpy

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.

---

It was just a very simple example. In my case the variable is of course not called ONE, but is a parameter used in a simulation program. If SI units are used, this parameter will not be one and it will be stored as a variable; however, if reduced units are used, this parameter will become one and will then either be a define or a const.

Quote:

---

Originally Posted by Salem

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

---

How do I do that; how can I see the assembly code that is generated?

Quote:

---

Originally Posted by Salem

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

---

Haha, that's a good one.

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).

Quote:

---

Originally Posted by Salem

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).

---

Agreed. You might be especially right with the last part because our program doesn't even work yet! Thanks for getting me on the right track.