It is not entirely true to say that optimization is impossible. I will go through the first few lines to show where conversions are not allowed either:
%addtmp = fadd double %x, %x
This first line can be safely converted to fmul double %x 2.0e+0 , but actually not optimized on most architectures ( fadd is usually as fast or fast as fmul and does not require the creation of a constant 2.0 ). Please note that the prohibition of overflow, this operation is accurate (like all scaling by degrees of two).
%addtmp1 = fadd double %addtmp, %x
This string can be converted to fmul double %x 3.0e+0 . Why is this a legal transformation? Since the calculation that %addtmp was accurate, therefore only one rounding was made if it was calculated as x * 3 or x + x + x . Since these are the basic operations of IEEE-754 and therefore are correctly rounded, the result will be the same. How about overflow? None of them can overflow if the other does not.
%addtmp2 = fadd double %addtmp1, %x
This is the first line that cannot be legally converted to a constant * x. 4 * x will calculate accurately without rounding, while x + x + x + x performs two rounds: x + x + x rounded once, and then adding x can be repeated a second time.
%addtmp3 = fadd double %addtmp2, %x
The same thing here; 5 * x will have one rounding; x + x + x + x + x takes three.
The only line that can be converted favorably replaces x + x + x with 3 * x . However, the subexpression x + x already present elsewhere, so the optimizer can easily refuse to use this transformation (since it can take advantage of the existing partial result if it does not).
source share