search for: uitofp

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...

...hrough "clang -c -emit-llvm" and then through "opt -O2 -S", produces the following IR: define <4 x float> @to_float4(i32 %in.coerce) nounwind uwtable readnone { entry: %0 = bitcast i32 %in.coerce to <4 x i8> %1 = extractelement <4 x i8> %0, i32 0 %conv = uitofp i8 %1 to float %vecinit = insertelement <4 x float> undef, float %conv, i32 0 %2 = extractelement <4 x i8> %0, i32 1 %conv2 = uitofp i8 %2 to float %vecinit3 = insertelement <4 x float> %vecinit, float %conv2, i32 1 %3 = extractelement <4 x i8> %0, i32 2 %conv4 =...

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.

Hi all, I seem to be unable to cast a vector of integers to a vector of floats (uitofp [4 x i8] to [4 x float], to be exact). It hits an assert in LegalizeDAG.cpp line 5433: "Unknown int value type". The Assembly Language Reference Manual's definition of uitofp doesn't indicate that this is unsupported, so it looks like a bug to me. I'm on an x86 system by the w...

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

...llvm.org/docs/LangRef.html describes the difference between "ordered" and "unordered" as pertaining to QNAN operands, with no mention of negative zero. I tried fixing the issue, but then the following test in cast-int-fcmp-eq-0.ll fails: ; CHECK-LABEL: @i32_cast_cmp_oeq_int_n0_uitofp( ; CHECK: uitofp ; CHECK: fcmp oeq define i1 @i32_cast_cmp_oeq_int_n0_uitofp(i32 %i) { %f = uitofp i32 %i to float %cmp = fcmp oeq float %f, -0.0 ret i1 %cmp } Is this test really justified, or is it just reinforcing an oversight? - Arch D. Robison -------------- next part -------------- An...

On Sat, Jun 21, 2008 at 4:24 PM, Nicolas Capens <nicolas at capens.net> wrote: > I seem to be unable to cast a vector of integers to a vector of floats > (uitofp [4 x i8] to [4 x float], to be exact). It hits an assert in > LegalizeDAG.cpp line 5433: "Unknown int value type". The Assembly Language > Reference Manual's definition of uitofp doesn't indicate that this is > unsupported, so it looks like a bug to me. I'm on an x86...

...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` for `sext` and...

...gn 8 ret void } If you run opt -instcombine on this, this transforms into define void @bitcast_alias_scalar(float* noalias %source, float* noalias %dest) nounwind { entry: %tmp2 = load float* %source, align 8 %0 = fptoui float %tmp2 to i32 %call = call i32 @func_i32(i32 %0) nounwind %1 = uitofp i32 %call to float store float %1, float* %dest, align 8 ret void } Note the fptoui / uitofp conversions to the underlying function's argument / return type. I would expect this to bitcast the arguments and call the underlying function. This transformation happens in InstCombiner::transfo...

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 scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110926/be6406e1/attachment.html>

...; preds = %Brancher %3 = srem i64 30, %1 ; <i64> [#uses=1] %4 = getelementptr inbounds i8* %0, i64 %3 ; <i8*> [#uses=1] %5 = load i8* %4 ; <i8> [#uses=1] %PeekResult = uitofp i8 %5 to double ; <double> [#uses=0] %6 = load double* %DoubleVar2 ; <double> [#uses=1] store double 0x40619C4E80000000, double* %DoubleVar %7 = srem i64 178, %1 ; <i64> [#uses=1] %8 = getelementptr inbounds i8* %0, i6...

...'mul double 1.0e300, 1.0e300' produce +infinity or is it undefined? I think LLVM should treat floating-point overflows consistently. On a similar note, what is the result of division by zero for fdiv? infinity or undefined? The manual needs to state the rounding mode of the fptrunc, uitofp, and sitofp instruction (if only to say it's undefined). I recommend round-to-nearest. What is the behavior of alloca if there is insufficient memory? null or undefined behavior? I'm attaching another round of changes. Please verify that they are correct. Best Regards, Jon -------...

...ning this on x86 ubuntu. after cd $build_dir cmake $src_root make The first strange this is that if I go into build_dir/test and type "make", it does nothing. In $build_dir, with "make check", I get errors like: /home/rkotler/llvmc/build/test/Analysis/CostModel/X86/Output/uitofp.ll.script: line 1: /home/rkotler//home/rkotler/llvmc/build/./bin/llvmc/build/./bin/llc: No such file or directory Certainly, ./bin/llc exists rkotler at mipssw006:~/llvmc/build$ ls ./bin/llc ./bin/llc

> 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

...k LLVM should treat floating-point overflows consistently. On a similar > note, what is the result of division by zero for fdiv? infinity or > undefined? IEEE also specifies these, but I don't know the answer off-hand. > The manual needs to state the rounding mode of the fptrunc, uitofp, and > sitofp instruction (if only to say it's undefined). I recommend > round-to-nearest. Everything is implicitly assumed to be in the default rounding mode. -Chris -- http://nondot.org/sabre/ http://llvm.org/

...instcombine on this, this transforms into > define void @bitcast_alias_scalar(float* noalias %source, float* noalias > %dest) nounwind { > entry: > %tmp2 = load float* %source, align 8 > %0 = fptoui float %tmp2 to i32 > %call = call i32 @func_i32(i32 %0) nounwind > %1 = uitofp i32 %call to float > store float %1, float* %dest, align 8 > ret void > } > > > Note the fptoui / uitofp conversions to the underlying function's argument > / return type. I would expect this to bitcast the arguments and call the > underlying function. This transform...

...o we propose to change the following from undef to poison: - insertelement/extractelement (element index out of range) - shufflevector (undef elements in shuffle mask) - alloca (allocating zero bytes) ? - load (load value with different type from written value) - GEP inrange - fptrunc/fptoui/fptosi/uitofp/sitofp (overflow) ? - llvm.ctlz.* and friends (is_zero_undef) ? Some of these are no brainers, others may need a bit of discussion. Please let us know if you have thoughts and/or concerns about this. Thanks, Nuno

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 <Kristof.Beyls at arm.com&g...

...vector - we just perform the operation on extracted elements rather than on the input vectors themselves. In the PR you linked, there is an example that shows the difference (simplified to <2 x double> for brevity): define dso_local <2 x double> @test(i64 %a, i64 %b) { entry: %conv = uitofp i64 %a to double %conv1 = uitofp i64 %b to double %vecinit = insertelement <2 x double> undef, double %conv, i32 0 %vecinit2 = insertelement <2 x double> %vecinit, double %conv1, i32 1 ret <2 x double> %vecinit2 } The inputs here are scalars so I suppose it is quite possi...

...loat 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 can be expres...