Why doesn't a compiler optimize floating-point *2 into an exponent increment?
I've often noticed gcc converting multiplications into shifts in the executable. Something similar might happen when multiplying an int and a float. For example, 2 * f, might simply increment the exponent of f by 1, saving some cycles. Do the compilers, perhaps if one requests them to do so (e.g. via -ffast-math), in general, do it?
Are compilers generally smart enough to do this, or do I need to do this myself using the scalb*() or ldexp()/frexp() function family?
Solution 1:
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:
- Bitwise convert into integer.
- Increment the exponent.
- Bitwise convert back to floating-point.
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.
Solution 2:
On modern CPUs, multiplication typically has one-per-cycle throughput and low latency. If the value is already in a floating point register, there's no way you'll beat that by juggling it around to do integer arithmetic on the representation. If it's in memory to begin with, and if you're assuming neither the current value nor the correct result would be zero, denormal, nan, or infinity, then it might be faster to perform something like
addl $0x100000, 4(%eax) # x86 asm example
to multiply by two; the only time I could see this being beneficial is if you're operating on a whole array of floating-point data that's bounded away from zero and infinity, and scaling by a power of two is the only operation you'll be performing (so you don't have any existing reason to be loading the data into floating point registers).