Bug 52316 - Loops with floating-point iteration variables not optimized away, though result is not used
Summary: Loops with floating-point iteration variables not optimized away, though resu...
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.7.0
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: missed-optimization
Depends on: 14886
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-20 14:18 UTC by Tobias Burnus
Modified: 2024-04-11 02:42 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2012-02-20 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2012-02-20 14:18:07 UTC
The following program takes 7.5s without optimization and 1.5s with -O1 to -Ofast. However, for -Ofast, I had expected that the loops are optimized away. However, that does not seem to happen.

With "ifort -fast", the program takes "0.0s".


Found at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/5ee459a4ddaeab9e#

program hello
implicit none
real :: x, y, n, i, j, t1, t2
call CPU_TIME(t1)
n = 30000.0
j = 1.0
do while (j < n)
i = 1.0
do while (i < n)
x = sin(45.0) * asin(0.5) * sqrt(5.000000) * atan(2.5555)
 i = i + 1.0
  end do
j = j + 1
end do
call CPU_TIME(t2)
print *, t2-t1
!call sleep(10)
end program hello
Comment 1 Jakub Jelinek 2012-02-20 15:07:27 UTC
Is it sufficiently common to do something that insane though?
We optimize away the dead code in there of course, but the problem is that it uses a floating point iterator.  I guess our number of iterations analysis just gives up when the IV is floating, here for known compile time constant init value and condition operand if both values are sufficiently small we could compute the number of iterations anyway, but as soon as adding 1 to a floating point value doesn't change it, for IEEE single when the value is 16777216.0f,
you end up with an endless loop, and that should be honored even for -Ofast.
Comment 2 Richard Biener 2012-02-20 15:08:05 UTC
can not prove finiteness of loop 1
can not prove finiteness of loop 2

number of iteration analysis does not work on non-integral IVs.
Comment 3 Andrew Pinski 2012-02-20 21:47:44 UTC
Related to PR 14886.
Comment 4 Tobias Burnus 2012-02-21 08:50:57 UTC
(In reply to comment #1)
> Is it sufficiently common to do something that insane though?

Well, seemingly, other vendors answer this question with yes. The loop is optimized away with pathf95, openf90, ifort and crayftn.

Whether it is common? I don't know. Some problems can naturally be expressed with loops which use floating-point (FP) iteration variables (IV). Though, I assume that a simple FP count ("r = r + 1.0") should be a bit rarer. The feature was seemingly popular enough that Fortran 77 introduced real/complex IV in DO loops.

On the other hand, loops with FP IV are ill defined - and that's the presumably the reason why Fortran 90 has deleted the feature (FP IV in DO loops). But using WHILE/DO WHILE one can still use floating-point IV - as one can do in C/C++.