similar to: [LLVMdev] Reasoning about Floating Point in Optimizations

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

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

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

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

Ulrich offered to do it instead since I expect he can get it done much faster than me. Instead I'm doing SIToFP and UIToFP. Ulrich said he wasn't going to be able to get to it for a couple of weeks, but that was a week or two ago. Ulrich? -----Original Message----- From: Cameron McInally <cameron.mcinally at nyu.edu> Sent: Tuesday, October 01, 2019 10:21 AM To: Kristof Beyls

Hi, I've been investigating the StructurizeCFG pass, and it looks like it has trouble handling CFG edges that break out of a loop and go directly to the function exit. Am I running up against a bug in the structurizer, or a general limitation of the algorithm used? As an aside, is there any documentation for the algorithm used? Is it based on a published paper? The input IR I have is the

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

On Thu, Nov 8, 2018 at 11:35 PM Fabian Giesen via llvm-dev < llvm-dev at lists.llvm.org> wrote: > What is so complicated about these? Shouldn't they just correspond to > two compares + selects? > > To give a concrete example, x86 MIN[SP][SD] and MAX[SP][SD], > respectively, correspond exactly to > > MIN*: select(a < b, a, b) (i.e. "a < b ? a : b")

Hi Arsen, On Oct 9, 2013, at 4:53 AM, Arsen Hakobyan <artinetstudio at gmail.com> wrote: > Hi all, > > I have the following test case: > #define FLT_EPSILON 1.19209290E-7 > > int err = -1; > int main() > { > float a = 8.1; > if (((a - 8.1) >= FLT_EPSILON) || ((a - 8.1) <= -FLT_EPSILON)) { //I am > using FLT_EPSILON to check whether (a != 2.0).

Hi all, I have the following test case: #define FLT_EPSILON 1.19209290E-7 int err = -1; int main() { float a = 8.1; if (((a - 8.1) >= FLT_EPSILON) || ((a - 8.1) <= -FLT_EPSILON)) { //I am using FLT_EPSILON to check whether (a != 2.0). err = 1; } else { err = 0; } return 0; } with -O3 optimization level clang generates already incorrect LLVM IR: ; Function Attrs:

* Sanjay Patel via llvm-dev <llvm-dev at lists.llvm.org> [2019-10-01 09:44:54 -0400]: > Let's change the example to eliminate suspects: > #include <math.h> > int is_nan(float x) { > /* > The following subclauses provide macros that are quiet (non > floating-point exception raising) > versions of the relational operators, and other comparison

On Sep 29, 2010, at 8:35 AMPDT, Ralf Karrenberg wrote: > Hello everybody, > > I have stumbled upon a test case (the attached module is a slightly > reduced version) that shows extremely reduced performance on linux > compared to windows when executed using LLVM's JIT. > > We narrowed the problem down to the actual code being generated, the > source IR on both systems

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

Sounds like the select lowering issue is definitely separate from the FENV work. Is there a bug report with a C or IR example? You want to generate compare and branch instead of a cmov for something like this? int foo(float x) { if (x < 42.0f) return x; return 12; } define i32 @foo(float %x) { %cmp = fcmp olt float %x, 4.200000e+01 %conv = fptosi float %x to i32 %ret = select

On 23-Jul-08, at 12:15 PM, David Greene wrote: > On Monday 21 July 2008 15:21, Stefanus Du Toit wrote: > >> We would like to extend the vector operations in llvm a bit. We're >> hoping to get some feedback on the right way to go, or some starting >> points. I had previously had some discussion on this list about a >> subset of the changes we have in mind. >

The LLVM 2.6-compatible IR below is derived from the HLVM test suite and is one of the things I've noticed going wrong. However, I just discovered that it works with LLVM 2.6 and with LLVM SVN when run through lli or llc without -tailcallopt but when I use: $ llvm-as -f aout.ll $ llc -tailcallopt -f aout.bc -o aout.s $ gcc -lm aout.s -o aout and the latest LLVM SVN it starts to print

Hi LLVMdev, In the specification of llvm ir, the select operation can takes a condition of vector type, 'select' Instruction Syntax: <result> = select *selty* <cond>, <ty> <val1>, <ty> <val2> *; yields ty* *selty* is either i1 or {<N x i1>} Overview: The 'select' instruction is used to choose one value based on a condition,

This is indeed a bug. I get a different error on my machine. Until we solve this bug, as a workaround, you can use the <4 x float> type for which the vselect works. From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Fan Dawei Sent: Wednesday, October 19, 2011 10:10 To: LLVMdev at cs.uiuc.edu Subject: [LLVMdev] Error when cond of select instruction is

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

Hi all, Consider the following snippet, the aim of which is to convert a double to a signed i16, returning 0 if not exactly representable: define i16 @foo(double) { top: %1 = fptosi double %0 to i16 %2 = sitofp i16 %1 to double %3 = fcmp une double %2, %0 %4 = select i1 %3, i16 0, i16 %1 ret i16 %4 } Of course, if the value is out-of-range, the result of fptosi is undefined.