similar to: fptosi undefined behaviour

On 22 January 2016 at 12:20, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> 1) I realise this is a somewhat silly question, but is this still >> acceptable "undefined behaviour"? > > Yes, it is. I always thought these out-of-range instructions did produce an "undef" rather than allowing fully-general undefined behaviour (otherwise we

I would be interested in learning what the set of used semantics for float-to-int conversion is. If the only two used are 1) undefined behavior if unrepresentable and 2) saturate to int_{min,max} with NaN going to zero, then I think it makes sense to expose both of those natively in the IR. If the set is much larger, I think separate intrinsics for each behavior would make sense. It would be nice

Hi everyone! The fptoui/fptosi instructions are currently specified to return a poison value if the rounded-towards-zero floating point number cannot be represented by the target integer type. The motivation for this behavior is that overflowing float to int casts in C are undefined behavior. However, many newer languages prefer to have a float to integer cast that is well-defined for all input

Hi LLVMdev, In the specification of llvm ir, the select operation can takes a condition of vector type, 'select' Instruction Syntax: <result> = select *selty* <cond>, <ty> <val1>, <ty> <val2> *; yields ty* *selty* is either i1 or {<N x i1>} Overview: The 'select' instruction is used to choose one value based on a condition,

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*

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 =

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

This is indeed a bug. I get a different error on my machine. Until we solve this bug, as a workaround, you can use the <4 x float> type for which the vselect works. From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Fan Dawei Sent: Wednesday, October 19, 2011 10:10 To: LLVMdev at cs.uiuc.edu Subject: [LLVMdev] Error when cond of select instruction is

Hi Rotem, What do you mean by "you can use the <4 x float> type for which the vselect works". Do you mean that then back-end can correctly split the operands when it is a four elements vector? I've try that, but it still fails. On Wed, Oct 19, 2011 at 4:21 PM, Rotem, Nadav <nadav.rotem at intel.com> wrote: > This is indeed a bug. I get a different error on my

On 8 January 2018 at 11:15, Kaylor, Andrew via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Kevin, > > Thanks for reaching out about this, and thanks especially for offering to > help. I've had some other priorities that have prevented me from making > progress on this recently. > > As far as I know, there is no support at all in clang for handling the >

Hi, I have some IR module from random generation (mostly ineffective instructions). It has a function with void return, and two function arguments where one is a reference. Therefore, I expect every instruction not altering the value at the 2nd arguments address should be ineffective. Here is the function definition (see below for full ll): define void @_Z27entityMainDataInputCallbackdRd(double

On 01/08/2018 07:06 PM, Richard Smith via llvm-dev wrote: > On 8 January 2018 at 11:15, Kaylor, Andrew via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Hi Kevin, > > Thanks for reaching out about this, and thanks especially for > offering to help. I've had some other priorities that have > prevented

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

Hi Kevin, Thanks for reaching out about this, and thanks especially for offering to help. I've had some other priorities that have prevented me from making progress on this recently. As far as I know, there is no support at all in clang for handling the FENV_ACCESS pragma. I have a sample patch somewhere that I created to demonstrate how the front end would create the constrained intrinsics

On 8 Jan 2018 19:50, "Hal Finkel via cfe-dev" <cfe-dev at lists.llvm.org> wrote: On 01/08/2018 07:06 PM, Richard Smith via llvm-dev wrote: On 8 January 2018 at 11:15, Kaylor, Andrew via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi Kevin, > > Thanks for reaching out about this, and thanks especially for offering to > help. I've had some other

[+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

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,

If fptosi takes 0.9 -> 0, then that is not 'rounding' in any sense I'm aware of (IEEE754 or otherwise). Rounding (in the IEE754 sense) determines how a number is converted when it is halfway between two candidate results. (see round(), ceil(), floor()). fptosi seems to model the behavior of a C cast from float to int, which truncates the fractional bits (as in trunc()). Steve

On 5/16/2017 6:30 AM, Sanjay Patel wrote: > Thanks for posting this question, Julia. > > I had a similar question about a signed min/max variant here: > http://lists.llvm.org/pipermail/llvm-dev/2016-November/106868.html > > The 2nd version in each case contains a canonical max/min > representation in IR, and this could enable more IR analysis. > A secondary advantage is

Hi, This message is a result of a discussion of backend optimization for sub(max) pattern(https://reviews.llvm.org/D25987), which can be either converted to unsigned min-max or unsigned saturation instruction(if the target supports it). Currently these versions of the code produce different IR(and we need to manage both types in backend): (1.16) void foo(unsigned short *p, unsigned short max,