search for: 1000.0f

Hi LLVM-ers, I'd like to eliminate dead loop with floating point counter using LLVM, but the following loop wasn't optimized by opt. void func() { float i; for (i = 0.0f; i < 1000.0f; i += 1.2f) { } } $ clang -emit-llvm-bc floop.c $ opt -std-compile-opts floop.bc | llvm-dis define void @func(...) nounwind { entry: br label %forinc forinc: ; preds = %forinc, %entry

Good evening all, Inspired by http://llvm.org/bugs/show_bug.cgi?id=3299, I've spent the last few hours looking at various test cases involving float point variables in loops and trying to identify some of our short comings on the optimization front. Before I go any further, I want to share my findings with the community and ask for feedback on how best to approach this. Essentially,

On Jan 8, 2009, at 4:36 AM, Syoyo Fujita wrote: > Hi LLVM-ers, > > I'd like to eliminate dead loop with floating point counter using > LLVM, but the following loop wasn't optimized by opt. > > void > func() { > float i; > for (i = 0.0f; i < 1000.0f; i += 1.2f) { > } > } FWIW, LLVM optimizer can eliminate this loop if i is incremented by 1.0f

Hi Devang, Thanks. Yes, in the case variable i incremented by 1.0f is optimized. I don't know why... Anyway, I've filed this problem into bugzilla(Bug 3299) -- Syoyo On Fri, Jan 9, 2009 at 12:42 AM, Devang Patel <dpatel at apple.com> wrote: > > On Jan 8, 2009, at 4:36 AM, Syoyo Fujita wrote: > >> Hi LLVM-ers, >> >> I'd like to eliminate dead loop

Does this look okay? : Time: 1:15.50 of 4:13.73, Bitrate: 133.3 How about? : <snip from=ogg123.c> info.u_time = ov_time_total (&vf, -1); /* Seconds with double precision */ gettimeofday (&start_time, NULL); t_min = (long) info.u_time / (long) 60; t_sec = info.u_time - 60 * t_min; while (! eos) { gettimeofday (&cur_time, NULL); c_min = (long)

Thanks for many comments. The loop with finite fp values(which could be representable in IEEE754 fp format) such like, void foo() { float i; for (i = 0.0f; i < 1000.0f; i += 1.2f) { } } could reach the end condition under any fp rounding mode, and eliminating the loop has no side effects. (for example, floating point control register does not change because the increment does

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 On

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