search for: sitofp

Hi all, Does PTX backend support llvm sitofp instruction? I failed to compile my llvm source when use llc -march=ptx32. The reason is that the source has a sitofp instruction. After i changed the instruction into uitofp manually, it passed. Thanks in advance, best, Yabin -------------- next part -------------- An HTML attachment was scrub...

...vectorizers so pardon the possibly stupid question) in the example you gave, why do you need SCEV to analyze the increment to vectorize the loop (i.e how does it help)? What are some other concrete cases you'll want to optimize? - I presume you'll want SCEV expressions for `sitofp` and `uitofp`. (The most important question:) With these in the game, what is the canonical representation of SCEV expressions that can be expressed as, say, both `sitofp(A + B)` and `sitofp(A) + sitofp(B)`? Will we have a way to mark expressions (like we have `nsw` and `nuw` f...

> Does PTX backend support llvm sitofp instruction? Seems it doesn't support sitofp, search "Conversion to f32" in PTXInstrInfo.td. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667

Hello, As I understand, in LLVM IR it cannot be determined whether a register of type int is signed or unsigned. If one wants to convert an integer to a double, which instruction should be used:  "uitofp" or "sitofp" ? We track the values taken by all load instructions and we process them using a function. If the value is a pointer, we use int64 as the type of the function argument. But in case the load instruction loads from a scalar, we need to convert it to a unique type, which we chose to be DoubleT...

When the uitofp and sitofp instructions convert e.g. from i64 to float, what rounding mode do they use? Answers in the form a patch to LangRef.html would be great! Thanks, Jay.

Hello LLVMer's I am now trying to fix a bug PR9473. sitofp instruction in LLVM IR is converted to vcvtsi2sd(also applied to vcvtsi2ss case) for x86/AVX backend, but vcvtsi2sd is somewhat odd instruction format. VCVTSI2SD xmm1, xmm2, r/m32 VCVTSI2SD xmm1, xmm2, r/m64 bits(127:64) of xmm2 is copied to corresponding bits of xmm1, thus in many case xmm1 and...

On Wed, Jul 24, 2013 at 4:03 AM, Jay Foad <jay.foad at gmail.com> wrote: > When the uitofp and sitofp instructions convert e.g. from i64 to > float, what rounding mode do they use? Answers in the form a patch to > LangRef.html would be great! The default rounding mode, just like every other floating-point operation. -Eli

...test12 > +; CHECK-NEXT: and i32 > +; CHECK-NEXT: add nsw Why not check for 'i32' after the add? Isn't the entire point of this patch to shrink the add in cases like this? > +; CHECK-NEXT: sext i32 > +; CHECK-NEXT: ret i64 > +} > Index: test/Transforms/InstCombine/add-sitofp.ll > =================================================================== > --- test/Transforms/InstCombine/add-sitofp.ll (revision 127153) > +++ test/Transforms/InstCombine/add-sitofp.ll (working copy) > @@ -1,4 +1,5 @@ > ; RUN: opt < %s -instcombine -S | grep {add nsw i32} >...

Hi! I've attached a patch which takes care of the issues mentioned (and adds two tests). -- Sanjoy Das http://playingwithpointers.com -------------- next part -------------- A non-text attachment was scrubbed... Name: ripple-bucket.diff Type: text/x-diff Size: 3318 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110308/0814e3e8/attachment.diff>

...form of (float)x + 1 => (float)(x + 1) is bogus. > On Mar 20, 2017, at 10:41 AM, Sanjay Patel via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Looks broken to me; I don't think there's UB in the original program. > > The fold in visitFAdd() should check if the sitofp is guaranteed to produce an exact result? Ie, if the int value input to the sitofp could possibly be different when converted back using fptosi, then the transform does not work. > > define float @test(i32 %x) { > %mul = mul i32 %x, 58 > %conv = sitofp i32 %mul to float > %add...

...: (1) for (float i = 0.5; i < 0.75; i+=0.05) {} → i is a "primary" IV And for *secondary*: (2) for (int i = 0, float x = start; i < N; i++, x += delta) {} → x is a "secondary" IV Now I'm working only on (2) - I presume you'll want SCEV expressions for `sitofp` and `uitofp`. [Demikhovsky, Elena] I'm adding these expressions, of course. They are similar to "truncate" and "zext", in terms of implementation. (The most important question:) With these in the game, what is the canonical representation of SCEV expressions that...

...is is definitely not the case with PPC). But what I am proposing here is actually handling something like this: define dso_local <2 x double> @test(<2 x i64> %a) { entry: %vecext = extractelement <2 x i64> %a, i32 0 %vecext1 = extractelement <2 x i64> %a, i32 1 %conv = sitofp i64 %vecext to double %conv2 = sitofp i64 %vecext1 to double %vecinit = insertelement <2 x double> undef, double %conv, i32 0 %vecinit3 = insertelement <2 x double> %vecinit, double %conv2, i32 1 ret <2 x double> %vecinit3 } With this type conversion, InstCombine will actu...

This C program produces different results with -O0 and -O3 optimization levels. #include <stdio.h> float test(unsigned int arg) { return (float)((int)(arg * 58)) + 1; } int main() { printf("%d\n", (int)test((unsigned int)-831710640)); } O0 result is -994576896 O3 result is -994576832 It happens because LLVM (specifically instcombine) does the following transformation:

...:64-S128-ni:1" target triple = "x86_64-unknown-linux-gnu" define void @test(i64 %v1, i32 %v2, i64* %addr) { entry: br label %loop loop: %iv = phi i64 [%v1, %entry], [%iv.inc, %loop] %iv2 = phi i32 [%v2, %entry], [%5, %loop] %0 = trunc i64 %iv to i32 %1 = sub i32 %iv2, %0 %2 = sitofp i32 %1 to double %3 = sub i64 0, %iv %4 = trunc i64 %3 to i32 %5 = sub i32 %1, %4 %iv.inc = add i64 %iv, 1 store i64 %iv.inc, i64* %addr, align 8 br i1 undef, label %loop, label %exit exit: ret void ; uselistorder directives ---- ; uselistorder i64 %iv, {2, 1, 0} } — IVUsers output (opt...

...what I am proposing here is actually handling something like this: >> define dso_local <2 x double> @test(<2 x i64> %a) { >> entry: >> %vecext = extractelement <2 x i64> %a, i32 0 >> %vecext1 = extractelement <2 x i64> %a, i32 1 >> %conv = sitofp i64 %vecext to double >> %conv2 = sitofp i64 %vecext1 to double >> %vecinit = insertelement <2 x double> undef, double %conv, i32 0 >> %vecinit3 = insertelement <2 x double> %vecinit, double %conv2, i32 1 >> ret <2 x double> %vecinit3 >> } &gt...

...gt; C and C++ have what's called "integer promotion rules", which apply to > most expressions involving types smaller than int and insert an > implicit promotion to int before anything else happens (in this case > another implicit conversion to double). > >> Can a sitofp i8 %3 to double be done or is it wrong? > > That's fine, in fact LLVM optimizes the function to use that itself. Are you saying that instruction will be optimized by LLVM in this case?

I always thought that bitcast was a no-op internal llvm thing to fit the IR type system. I currently use sitofp, but I see your point. On Fri, Apr 17, 2015 at 1:04 AM, James Molloy <james at jamesmolloy.co.uk> wrote: > Hi Dave, > > You can still bitcast between i32 and float, for example. > > Cheers, > > James > > On Fri, 17 Apr 2015 at 09:03 Dave Pitsbawn <dpitsbawn at...

I tried to emit IR for a function that returns the sum between an signed char and a double in C++, just to see how Clang handles type implicit casting. Can you explain me why Clang converted the char type into a 32-bit integer type before casting it to a floating point? Can a sitofp i8 %3 to double be done or is it wrong? define i32 @_Z5sumad(i8 signext %x, double %y) #0 { %1 = alloca i8, align 1 %2 = alloca double, align 8 store i8 %x, i8* %1, align 1 store double %y, double* %2, align 8 %3 = load i8, i8* %1, align 1 %4 = sext i8 %3 to i32 %5 = sitofp i32 %4 t...

...:64-S128-ni:1" target triple = "x86_64-unknown-linux-gnu" define void @test(i64 %v1, i32 %v2, i64* %addr) { entry: br label %loop loop: %iv = phi i64 [%v1, %entry], [%iv.inc, %loop] %iv2 = phi i32 [%v2, %entry], [%5, %loop] %0 = trunc i64 %iv to i32 %1 = sub i32 %iv2, %0 %2 = sitofp i32 %1 to double %3 = sub i64 0, %iv %4 = trunc i64 %3 to i32 %5 = sub i32 %1, %4 %iv.inc = add i64 %iv, 1 store i64 %iv.inc, i64* %addr, align 8 br i1 undef, label %loop, label %exit exit: ret void ; uselistorder directives ---- ; uselistorder i64 %iv, {2, 1, 0} } — … snip So, to get b...

...= load i32, i32* getelementptr inbounds (%struct.R, %struct.R* @r, i32 0, i32 0, i32 0, i64 3, i32 1), align 4, !tbaa !9 %add1 = add nsw i32 %add, %2 %3 = load i32, i32* getelementptr inbounds (%union.U, %union.U* @u, i32 0, i32 0), align 4, !tbaa !2 %add2 = add nsw i32 %add1, %3 %conv = sitofp i32 %add2 to float %4 = load float, float* bitcast (%union.U* @u to float*), align 4, !tbaa !11 %add3 = fadd float %conv, %4 %5 = load i32, i32* getelementptr inbounds (%struct.Q, %struct.Q* @q, i32 0, i32 1, i32 0), align 4, !tbaa !2 %conv4 = sitofp i32 %5 to float %add5 = fadd float %...