similar to: [LLVMdev] strange floating point problem

Hi Alex, > The IL looks fine. It is optimized so there are only the function > calls with the different constant double values as direct input. If I > change the values from double to i64 everything works fine! I've not seen similar problems. Is there any chance you can send more details? The .ll file itself, llc invocation options and LLVM version would help a lot. Other than

Hello everyone. I'm not an expert neither in llvm nor in x86 nor in IEEE standard for floating point numbers, thus any of my following assumptions maybe wrong. If so, I will be grateful if you clarify me what's goes wrong. But if my guesses are correct we possibly have a bug in fp arithmetics on x86. I have the following ir: @g = constant i64 1 define i32 @main() { %gval = load

Hi Guys, I was working on some floating point intensive benchmarks and realize that the floating point register allocation in llvm assumes that there are only 7 floating point registers in X86, whereas the hardware has 8. Line number 00266 assert(Reg >= X86::FP0 && Reg <= X86::FP6 && "Expected FP register!"); of X86FloatingPoint.cpp. Is there any reason for

On Tue, 18 Apr 2006 23:27:39 -0700 Evan Cheng <evan.cheng at apple.com> wrote: > Hi Simon, > > The x86 backend does generate scalar SSE2 instructions. For your > example, it should emit something like: Oh, how did you get this ? [...] > > There is nothing here that should cause an exception. Are you using a > release or cvs? CVS. >From what I remember,

Quoting Tim Northover <t.p.northover at gmail.com>: > On 24 April 2015 at 13:53, Tyler Denniston <tyler at csail.mit.edu> wrote: >> I'm wondering how I can create an atomic load and add instruction for >> floating point values. If I use IRBuilder::CreateAtomicRMW() I get the >> error message: "atomicrmw operand must have integer type". > >

Hi, I am not sure if this is the right mailing list to ask my question, if not, please refer me to the proper one. Is there any support for rounding modes in LLVM floating point? I looked in the assembler reference manual, and it doesn't seem so. I am thinking about choosing LLVM as one of the backends for my programming language Babel-17 (www.babel-17.com). Babel-17 features interval

On May 25, 2011, at 11:09 AM, aparna kotha wrote: > Hi Guys, > > I was working on some floating point intensive benchmarks and realize that the floating point register allocation in llvm assumes that there are only 7 floating point registers in X86, whereas the hardware has 8. > > Line number > 00266 assert(Reg >= X86::FP0 && Reg <= X86::FP6 &&

On Wed, 19 Apr 2006 19:28:34 +0100 Simon Burton <simon at arrowtheory.com> wrote: > > >From what I remember, this is a bug in debian libc: > some floating point flags are set incorrectly causing SIGFPE. > Can't find the bug report ATM. Oh, it just showed up on numpy-discussion: http://sources.redhat.com/bugzilla/show_bug.cgi?id=10 """ #include

Hi Tim, Thanks for your message! It turns out that the infrastructure (an outdated one) that I am working on is using gcc+dragonegg to generate llvm code: gcc -m32 -S -c -O0 -fplugin=$(DRAGONEGG_SO) -fplugin-arg-dragonegg-emit-ir $< -o $@.tmp It directly generates llvm code with fadd, etc. I'm not familiar with dragonegg plugin... Thanks, XIaochu On Wed, Mar 16, 2016 at 12:00 PM,

Dear there, I was trying to compile a code with only integer type variables and integer operations. Clang/llvm kept showing me llvm code with floating-point instructions (fmul, fadd, fptosi, etc.). Is there a way in Clang or llvm to stop the compiler from doing that? My experiment does not allow floating-point operations... Thanks, Xiaochu

> } while (__c11_atomic_compare_exchange_weak( > addr, &oldval, newval, memory_order_seq_cst, memory_order_relaxed)); Actually, I think this condition is inverted. Should be "while (!_c11...". Sorry about that. Tim.

On 11 May 2017 at 18:30, Michael Clark via llvm-dev <llvm-dev at lists.llvm.org> wrote: > I note that on your bug that you have stated that the branch is faster than > the conditional move. Faster code is a side effect of the fix in this > particular case. On the contrary: the faster code is pretty much the only reason this can happen before the rest of the FENV support lands.

Hello, I'm wondering how I can create an atomic load and add instruction for floating point values. If I use IRBuilder::CreateAtomicRMW() I get the error message: "atomicrmw operand must have integer type". I am using LLVM 3.4 and the only system I need to support is x86.

On Thu, 20 Apr 2006, Simon Burton wrote: >>> From what I remember, this is a bug in debian libc: >> some floating point flags are set incorrectly causing SIGFPE. >> Can't find the bug report ATM. > > Oh, it just showed up on numpy-discussion: > http://sources.redhat.com/bugzilla/show_bug.cgi?id=10 > > """ > #include <fenv.h> > void

Is there any intention of making floating absolute and negate primitive IR instructions? I ask because only a few days ago I was also faced with the task of implementing negate in my compiler, and finding no suitable IR instruction, simply subtracted from zero. But this is wrong. I could change my code to do the bit casting and fiddling, but I wonder: would that be lowered appropriately on all

I notice llvm provides both ordered and unordered variants of floating-point comparison. Which of these is the right one to use by default? I suppose the two criteria would be, in order of importance: 1. Which is more efficient (more directly maps to typical hardware)? 2. Which is more familiar (more like the way C and Fortran do it)?

On Sun, Mar 28, 2010 at 7:45 AM, Russell Wallace <russell.wallace at gmail.com> wrote: > I notice llvm provides both ordered and unordered variants of > floating-point comparison. Which of these is the right one to use by > default? I suppose the two criteria would be, in order of importance: > > 1. Which is more efficient (more directly maps to typical hardware)? You can

Hi Tim, Thank you for that. I was just trying to replicate the branch instruction under a new opcode, so I don’t think that returns a value. Plus the code I was testing out didn’t have a br or my newly added instruction but it still threw that error at me. Here’s the IR code I tested: ; ModuleID = ‘cc.c’ source_filename = “cc.c” target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128”

Hi Tim Northover, I just use Mac OS X, Intel Core i5. 'retValue' is initialized, computed, and then returned from 'myFunction', so I think this problem is not introduced by uninitialized value. In addition, '306205760' is not a meaningless value, but the result of truncating '140583176769504' to 32 bits. Actually, I instrumented some call instructions for value

Hello, everyone, I encounter a strange problem about llvm type i64 and C++ type int64_t. I instrumented a program to call the function 'myFunction' in the C++ shared library. 'myFunction' is something like this: int64_t myFunction() { int64_t retValue; ... std::cout << "retValue: " << retValue << "\n"; return retValue; }