I\'ve often noticed gcc converting multiplications into shifts in the executable. Something similar might happen when multiplying an int
and a float
. F
For example, 2 * f, might simply increment the exponent of f by 1, saving some cycles.
This simply isn't true.
First you have too many corner cases such as zero, infinity, Nan, and denormals. Then you have the performance issue.
The misunderstanding is that incrementing the exponent is not faster than doing a multiplication.
If you look at the hardware instructions, there is no direct way to increment the exponent. So what you need to do instead is:
There is generally a medium to large latency for moving data between the integer and floating-point execution units. So in the end, this "optimization" becomes much worse than a simple floating-point multiply.
So the reason why the compiler doesn't do this "optimization" is because it isn't any faster.