similar to: [LLVMdev] uitofp and sitofp rounding mode

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

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

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:

> 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

The fptrunc instruction states "If the value cannot fit within the destination type, ty2, then the results are undefined." This is fine, but what about other floating-point operations that can overflow? For example, does '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,

[+CC Andy] Hi Elena, I don't have any fundamental issues with teaching SCEV about floating point types, but given this will be a major change, I think a high level roadmap should be discussed on llvm-dev before we start reviewing and committing changes. Here are some issues that I think are worth discussing: - Core motivation: why do we even care about optimizing floating point

On Mon, 31 Mar 2008, Jon Sargeant wrote: > The fptrunc instruction states "If the value cannot fit within the > destination type, ty2, then the results are undefined." This is fine, but > what about other floating-point operations that can overflow? For example, > does 'mul double 1.0e300, 1.0e300' produce +infinity or is it undefined? It is defined by IEEE to

Thanks so much for your feedback Simon. I am not sure that what I am proposing here is at odds with what you're referring to (here and in the PR you linked). The key difference AFAICT is that the pattern I am referring to is probably more aptly described as "reducing scalarization" than as "vectorization". The reason I say that is that the inputs are vectors and the output

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

Absolutely. We do it for scalars, so it would likely be a matter of just extending it. But that is one example. The issue of extracting elements, performing an operation on each element individually and then rebuilding the vector is likely more prevalent than that. At least I think that is the case, but I'll do some analysis to see if it is so or not. On Sat, Jan 11, 2020 at 6:15 PM Craig

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

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, Lately we have come to realize how undef makes our life complicated.. Therefore in this email we propose to change the behavior of a few instruction to yield poison instead of undef in error cases. This follows the suggestion of Eli in https://reviews.llvm.org/D33654. Why is undef so bad? - I believe it's not possible to make newgvn correct with undef. See for example the discussion

Here is a patch containing all but one of the changes. I realized that the remainder/modulo discussion does indeed belongs to the srem instruction. The semantics of urem are obvious and need no further clarification. Best Regards, Jon 1572,1573c1572,1575 < notation (see below). Floating point constants must have a <a < href="#t_floating">floating point</a>

In InstCombineCompares.cpp, routine InstCombiner::FoldFCmp_IntToFP_Cst, there are these lines: // Comparisons with zero are a special case where we know we won't lose // information. bool IsCmpZero = RHS.isPosZero(); // If the conversion would lose info, don't hack on this. if ((int)InputSize > MantissaWidth && !IsCmpZero) return nullptr; Why check for positive

Chris Lattner wrote: > On Mar 31, 2008, at 5:07 PM, Jon Sargeant wrote: > >> Gordon Henriksen wrote: >>> Hi Jon, >>> Please you'll want to submit patches as unified diffs and as >>> attachments. >>> I notice you're using Thunderbird, so I refer you to this tip: >>>

I agree. There’s implementation-defined behavior on the conversion of (arg*58) to int, but that shouldn’t be at issue here. The transform 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

>What situations are they common in? ICC Vectorizer made a paradigm shift a while ago. If there aren’t a clear reason why something can’t be vectorized, we should try our best to vectorize. The rest is a performance modeling (and priority to implement) question, not a capability question. We believe this is a good paradigm to follow in a vectorizer development. It was a big departure from

On Oct 26, 2008, at 1:03 AM, Duncan Sands wrote: > Hi all, I plan to turn on the new type legalization infrastructure > "LegalizeTypes" by default tomorrow. This is a redesign/ > reimplementation > of the logic currently in LegalizeDAG that turns (for example) 64 bit > arithmetic on a 32 bit machine into a series of 32 bit operations. > As well > as being a

Hello all, I'm new to the llvm community. I'm learning how things work. I noticed that there has been some interest in improving how unions are handled. Bug 21725 is one example. I figured it might be a interesting place to start. I discussed this with a couple people, and below is a suggestion on how to represent unions. I would like some comments on how this fits in with how