similar to: [LLVMdev] Floating-Point Overflow check

On Jul 23, 2010, at 7:20 AM, Steffen Geißinger wrote: > i need to check if an overflow of an floating-point arithmetic operation occured. > Currently I'm doing something like this (for addition): > > (LHS > 0 && RHS > 0 && sum <= 0) || (LHS < 0 && RHS < 0 && sum >= 0) IEEE floating-point doesn't overflow like this; if the

Hello, i know that the result is infinte, but there are sill flags in the FPU which indicate that an overflow, underflow or div by zero occured. So isn't there an easy way to check if one of those flags is set? 2010/7/23 John McCall <rjmccall at apple.com> > On Jul 23, 2010, at 7:20 AM, Steffen Geißinger wrote: > > i need to check if an overflow of an floating-point

Hi, i'm currently building a small JIT compiler. For the language I need a runtime library for some special math functions. I think the best would be to compile the lib to bitcode and link it. The compiler should be integrated in a product and as of this, it must work under windows (VC10, 64bit). So is it possible to build the math lib with the mingw llvm-gcc build an link it later with 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

I wrote the following bit of code static APInt FloorOfQuotient(APInt a, APInt b) { unsigned bits = a.getBitWidth(); APInt q(bits, 1), r(bits, 1); APInt::sdivrem(a, b, q, r); * errs() << "sdivrem(" << a << ", " << b << ") = (" << q << ", " << r << ")\n"; * if (r == 0) return q; else {

Hi, I'm pursuing M.Tech course. As a part of the project work i'm using LLVM as back-end. My project area is "Enhancing the performance of V8 javascript engine using LLVM as a back-end". Now i'm writing code for shift left(SHL) operator. I had my own Value Structure .. it's like this Struct Value { void *val ; char type; } The "char type" holds

OK, the code for sdivrem in APInt.h is wrong. Here's what's written: static void sdivrem(const APInt &LHS, const APInt &RHS, APInt &Quotient, APInt &Remainder) { if (LHS.isNegative()) { if (RHS.isNegative()) APInt::udivrem(-LHS, -RHS, Quotient, Remainder); else APInt::udivrem(-LHS, RHS, Quotient, Remainder); Quotient =

I am having a problem with instruction selection with pattern fragments. With my custom target, in order to simplify code generation patterns, I do not allow a constant to be used in an instruction(mainly because they have declare before use semantics). Now the problem I am having is that I cannot get a instruction that contains pattern fragment that uses an immediate value to be selected before

On Thu, Sep 22, 2011 at 3:46 PM, sarath chandra <sarathcse19 at gmail.com>wrote: > Hi James, > > First i converted the void * to int* and then did FPToSI...then did SHL...( > because CreateShl only accepts integers... i pointer casted it to int64 type > first)... Below is the code snippet.... > > > lhs = mBuilder.CreateStructGEP(firstArg, 0); > lhs =

I've been playing around with llvm lately and I was wondering something about the bitcode instructions for basic arithmetic. Is there any plan to provide instructions that perform widening multiply, or add with carry? It might be written as: mulw i32 %lhs %rhs -> i64 ; widening multiply addw i32 %lhs %rhs -> i33 ; widening add addc i32 %lhs, i32 %rhs, i1 %c -> i33 ; add with carry

I'm looking at the documentation on Twine at http://llvm.org/docs/ProgrammersManual.html#llvm-adt-twine-h and it gives example code: void foo(const Twine &T); ... StringRef X = ... unsigned i = ... foo(X + "." + Twine(i)); How exactly does that last line work? Since addition is left associative, I would expect it to be parsed as (X + ".") ... so it's trying to add

Using the Thumb-2 target we see that ORN ( a | ^b) and BIC (a & ^b) have similar patterns, as we would expect: defm t2BIC : T2I_bin_irs<"bic", BinOpFrag<(and node:$LHS, (not node: $RHS))>>; defm t2ORN : T2I_bin_irs<"orn", BinOpFrag<(or node:$LHS, (not node: $RHS))>>; Compiling the following three works as expected: %tmp1 = xor i32

if I write: int z, x; ... z = (x >= k); -- where k is a constant The compiler always wants to translate this into: z = (x > (k-1)); In general this can often lead to better code (and it does for Mips 16 for sure), except at the boundary condition where k==-32768 Then it creates the literal -32769 which cannot be placed in a simple immediate field. That creates a lot of extra code for

Hi, The attached patch implements sub.ovf/mul.ovf intrinsics similarly to the recently added add.ovf intrinsics. These are useful for implementing some vm instructions like sub.ovf/mul.ovf in .NET IL efficiently. sub.ovf is supported in target independent lowering and on x86, while mul.ovf is only supported in the x86 backend. Please review

This adds a bunch of static functions that implement unsigned two's complement bignum arithmetic. They could be used to implement much of APInt, but the idea is they are enough to implement APFloat as well, which the current APInt interface is not suited for. Neil. -------------- next part -------------- Index: include/llvm/ADT/APInt.h

On 07/21/2013 09:49 AM, Star Tan wrote: > Hi all, > > > I have attached a patch file to reduce the polly-detect overhead. Great. > My idea is to avoid calling TypeFinder in Non-DEBUG mode, so > TypeFinder is only called in DEBUG mode with the DEBUG macro. This > patch file did this work with following modifications: > > > First, it keeps most of string information

Hi Sarath, It would have really helped if you had removed the commented out code and inlined the calls to your homemade helper functions before sending it... You are doing this, in LLVM IR: %0 = getelementptr %Value* %firstArg, i32 0 ; i8** %1 = load i8** %0 ; i8* %2 = bitcast i8* %1 to i64* %3 = getelementptr %Value* %secondArg, i32 0 ; i8** %4 = load i8** %3; i8* %5 = bitcast i8* %4 to i64*

Yeah, that's the fault...got the answer...... Thanks James for the help... Struggling with this for so many days....... On Thu, Sep 22, 2011 at 4:02 PM, James Molloy <James.Molloy at arm.com> wrote: > Hi Sarath,**** > > ** ** > > It would have really helped if you had removed the commented out code and > inlined the calls to your homemade helper functions before

Oh, no. I should have been more clear. The patch was not rejected, just lost in the daily shuffle. I already have my employer's approval to send this upstream, so I will prepare a patch against trunk this morning. > I proposed a similar patch to LLVM (left circular shift) around 10/2011. > > Parts of my patch did make it into trunk about a year after, but others > > did not.

Hi, > Both A and B are undef: > LHS = (undef & undef) | (undef & undef) = undef // Since ~undef = undef > RHS = undef > Thus transform is correct. LLVM documentation (http://llvm.org/docs/LangRef.html#undefined-values) suggests that it is unsafe to consider (a & undef = undef) and (a | undef = undef). "As such, it is unsafe to optimize or assume