search for: createfmull

Are you calling llvm_shutdown() at the end of your program? You should. valgrind reports "possible" leaks when it finds a pointer pointing inside a memory block (as opposed to at the first byte), and LLVM uses those a lot. llvm_shutdown() will free a lot of that memory, including the LLVMContext, which should remove any false leaks you might be seeing. On the other hand, the

Hi Sanjay, Thanks, I saw this flag and it's definitely should be considered, but it appeared to me to be static characteristic of target platform. I'm not sure how appropriate it would be to change its value from a front-end. It says "Has", while optional flag would rather say "Uses" meaning that implementation cares about floating point exceptions. Regards, Sergey

Hi again, It's partially done. My concern is that it won't be accepted as is because of adding the flag parameter in a lot of places. I'd like to show what it looks like (here, not on llvm-commit yet), maybe someone could suggest a better way. There are two sources of the flag: field of TargetOptions and function attribute. I had to add the later one for InstCombine pass. Still

I think I found the cause. It appears that FP operations and functions (I used combinations of CreateFMulL CreateFAdd and CreateFSub ) is MUCH slower than their integer equivalents. I mean really slower (20x slower or even more) Can It be the cause ? Does the FP binary ops are so slow ? -- Regards, Gabi http://bugspy.net

Hi! currently instcombine does not detect constant diagonal matrix times vector, for example a.xx * [2 0] + a.yy * [0 3] can be optimized to a * [2 3] I have implemented this for float. I know that this assumes x * 0 = 0 which is not ieee compliant but i post it here in case it is interesting for someone. on my wish list there is still an option for target independent optimizations to have x

Hi Jeffrey, Listed below the Full valgrind report (using latest revision r99309) The program creates many thousands of instructions and values as you can see from the report below ==20504== Memcheck, a memory error detector ==20504== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==20504== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for copyright info ==20504==