similar to: [LLVMdev] Loop elimination with floating point counter.

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

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

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

Hello, I'm working on using the LLVM JIT for a little project of mine, amazing work first off! I have a question about optimization passes. I initially have this function I've created, in python it looks like this: OS_end = 50OS_start = 0OS_timestep = 1birth_rate = .3population = 30.0for time in range(OS_start, OS_end, OS_timestep): births = birth_rate * population deaths = 0.1

On Jan 14, 2009, at 5:11 AM, Syoyo Fujita wrote: > Thanks for many comments. > > The loop with finite fp values(which could be representable in IEEE754 > fp format) such like, Sure, LLVM could definitely do this. If you're interested, I'd suggest starting by extending the existing code that we have to do this. The existing code just handles increments by unit constants,

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

Our frontend can guarantee that loads from globals are rematerializable and do not alias with any stores in any function in the given module. We'd like the optimization passes (and ideally the register allocator as well) to be able to use this fact. The globals are not constant "forever" but are constant during the calling of any given function in the module. There seem to

1.6.1 svn 190575: CC="cc" CXX="g++" LD="" AR="" RANLIB="" CFLAGS="" make -C menuselect CONFIGURE_SILENT="--silent" menuselect make[1]: Entering directory `/home/asterisk/rpmbuild/BUILD/asterisk-1.6.1/menuselect' gcc -m64 -march=native -mtune=native -floop-interchange -floop-strip-mine -floop-block -c -o

Hi LLVM-ers, I am trying to get a return type of a function(from bitcode file) with LLVM-C API, but there seems no appropriate API to do that. I've tried to do that with following code, ---- LLVMModuleRef M; LLVMMemoryBufferRef MemBuf; LLVMValueRef F; // Function LLVMTypeRef RetTy; char *ErrStr; // // -- Load shader module //

Ralf Karrenberg <Chareos at gmx.de> writes: > This sounds great! > > For my case, I only require some basic support, so I am optimistic > that your next few patches will provide everything I need. If my evil plan works out, within the next 10 or so patches we should be in a place where pushing everything up goes pretty quickly. It's about 8 TableGen patches and then a

Hello David, > I try to put [AVX] in the subject of patch mailings (to -commits) and > commit messages.  Once in a while I forget.  I'll try to remeber to send > semething to -dev when major stuff appears. Good. I am also trying to sending a patch to llvm-commits. It'd be better for me to use [AVX] prefix in the subject so that we can easily identify "This is an AVX

Hello, I've been playing around with the really simple example of not cache friendly loop like this: #define N 100 void foo(int** __restrict__ a, int** __restrict__ b) { for (int i = 0; i < N; ++i) for (int j = 0; j < N; ++j) a[j][i] += b[j][i]; } link to compiler explorer:

https://bugs.freedesktop.org/show_bug.cgi?id=65310 --- Comment #4 from Emil Velikov <emil.l.velikov at gmail.com> --- Cannot seem to reproduce $ export CFLAGS="-march=native -msse2 -mfpmath=sse -O3 -ffast-math -funroll-loops -fomit-frame-pointer -floop-interchange -floop-strip-mine -floop-block" export CXXFLAGS="$CFLAGS" # Build mesa with Gallium3D hardware drivers $

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

Hi Syoyo, > I am trying to get a return type of a function(from bitcode file) with > LLVM-C API, but there seems no appropriate API to do that. From my memory, this info is stored in the function type, so you could look at the function's type and get the info there. Looking the the API docs [1], I find that there is a simple method on Function called getReturnType(). You should thus be

Hi. I would like to partially apply a function to a list of arguments, and I don't know how to do this in R, without perhaps writing default values to the formals() of my function, or writing to the environment object of a function. For context, my definition of partially apply is: "fix some of the arguments, leaving the others as variables, return a new function that takes the un-fixed

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,

While building llvm & clang & libs by giving some optimization options to the building compiler, the following error happened: I think it is related to the passed -DCLS=64, because in file clang/lib/Frontend/Rewrite/RewriteModernObjC.cpp:6411 an enum member has the same name (CLS), so it does a macro-substitution with the passed value of CLS, ie. with 64, but which of course then breakes