llvm dev - Jan 2009 - [LLVMdev] Loop elimination with floating point counter.

Isn't "simplifying" the loop index to an integer also dependent on
precision issues? The following loop is infinite:

for (float i=0.0; i<...; i+=1.0) {}

where ... is a large "integral" float literal, e.g. 2^40. At some  
point, adding 1.0 to the loop index would not cause any changes  
because of precision issues. However, if the float type is replaced  
by some sufficiently large integer type, the loop terminates.

The necessary reasoning may be simpler though.

Greetings,
Martin Geisse

On Jan 8, 2009, at 6:34 PM, Owen Anderson wrote:
> It's because with 1.0f, the loop index is simplified into an integer.
> With 1.2f, it isn't.  The loop deletion pass is dependent on the loop
> analyses being able to determine that the loop is finite, which they
> don't attempt to do for loops with floating point indices.  Attempting
> to do so would require additional reasoning about floating point
> precision issues.
>
> --Owen
>

Martin,
> Isn't "simplifying" the loop index to an integer also
dependent on
> precision issues? The following loop is infinite:
>
> for (float i=0.0; i<...; i+=1.0) {}
>
> where ... is a large "integral" float literal, e.g. 2^40.
it is. But luckily at least llvm-gcc appears to be smart enough to  
check against the end
value. I've just tested the following snippet (compiled using llvm-gcc  
-c -O3 --emit-llvm)

void foo() {
     float f;
     for( f = 0.0; f < 100.0f; f += 1.0f ) {
     }
}
=>
define void @foo() nounwind readnone {
entry:
	ret void
}

void foo() {
     float f;
     for( f = 0.0; f < 101.0f; f += 1.0f ) {
     }
}
=>
define void @foo() nounwind readnone {
entry:
	br label %bb

bb:		; preds = %bb, %entry
	%f.0.reg2mem.0 = phi float [ 0.000000e+00, %entry ], [ %0, %bb ]		;  
<float> [#uses=1]
	%0 = add float %f.0.reg2mem.0, 1.000000e+00		; <float> [#uses=2]
	%1 = fcmp olt float %0, 1.010000e+02		; <i1> [#uses=1]
	br i1 %1, label %bb, label %return

return:		; preds = %bb
	ret void
}

So everything is fine here

Jan

I assume it checks that the end condition and the increment can both  
be represented precisely with integer types.

--Owen

On Jan 8, 2009, at 9:49 AM, Martin Geisse wrote:
> Isn't "simplifying" the loop index to an integer also
dependent on
> precision issues? The following loop is infinite:
>
> for (float i=0.0; i<...; i+=1.0) {}
>
> where ... is a large "integral" float literal, e.g. 2^40. At some
> point, adding 1.0 to the loop index would not cause any changes
> because of precision issues. However, if the float type is replaced
> by some sufficiently large integer type, the loop terminates.
>
> The necessary reasoning may be simpler though.
>
> Greetings,
> Martin Geisse
>
> On Jan 8, 2009, at 6:34 PM, Owen Anderson wrote:
>
>> It's because with 1.0f, the loop index is simplified into an
integer.
>> With 1.2f, it isn't.  The loop deletion pass is dependent on the
loop
>> analyses being able to determine that the loop is finite, which they
>> don't attempt to do for loops with floating point indices.   
>> Attempting
>> to do so would require additional reasoning about floating point
>> precision issues.
>>
>> --Owen
>>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

FWIW, I believe icc -O3 turns on the equivalent of -ffast-math by default.
I could be misremembering which compilers do this though :)
This flag allows you to make all kinds of nice simplfiying assumptions
about floating point.

On Thu, Jan 8, 2009 at 7:45 PM, Owen Anderson <resistor at mac.com>
wrote:
> I assume it checks that the end condition and the increment can both
> be represented precisely with integer types.
>
> --Owen
>
> On Jan 8, 2009, at 9:49 AM, Martin Geisse wrote:
>
>> Isn't "simplifying" the loop index to an integer also
dependent on
>> precision issues? The following loop is infinite:
>>
>> for (float i=0.0; i<...; i+=1.0) {}
>>
>> where ... is a large "integral" float literal, e.g. 2^40. At
some
>> point, adding 1.0 to the loop index would not cause any changes
>> because of precision issues. However, if the float type is replaced
>> by some sufficiently large integer type, the loop terminates.
>>
>> The necessary reasoning may be simpler though.
>>
>> Greetings,
>> Martin Geisse
>>
>> On Jan 8, 2009, at 6:34 PM, Owen Anderson wrote:
>>
>>> It's because with 1.0f, the loop index is simplified into an
integer.
>>> With 1.2f, it isn't.  The loop deletion pass is dependent on
the loop
>>> analyses being able to determine that the loop is finite, which
they
>>> don't attempt to do for loops with floating point indices.
>>> Attempting
>>> to do so would require additional reasoning about floating point
>>> precision issues.
>>>
>>> --Owen
>>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>