similar to: [LLVMdev] Float undef value propagation

On 12/9/13 2:13 PM, Raoux, Thomas F wrote: > > Constant propagation pass generates constant expression when undef is > used in float instructions instead of propagating the undef value. > > ; Function Attrs: nounwind > > define float @_Z1fv() #0 { > > entry: > > %add = fadd fast float undef, 2.000000e+00 > > ret float %add > > } > > Becomes:

----- Original Message ----- > From: "Philip Reames" <listmail at philipreames.com> > To: llvmdev at cs.uiuc.edu > Sent: Tuesday, December 10, 2013 2:55:36 PM > Subject: Re: [LLVMdev] Float undef value propagation > > > > On 12/9/13 2:13 PM, Raoux, Thomas F wrote: > > > > > > Constant propagation pass generates constant expression

You are right some cases would definitely not be right like undef + Nan -> undef. For 2.0f case I'm not sure either if any bits could be known. It seems that in general fadd( float undef, float %1) -> float %1 should always be safe and I just checked with latest code this doesn't happen. Do you think the right solution would be to add such optimization? Is there any reason why we

On 11 December 2013 20:08, Raoux, Thomas F <thomas.f.raoux at intel.com> wrote: > You are right some cases would definitely not be right like undef + Nan -> > undef. For 2.0f case I’m not sure either if any bits could be known. Do you have an example where that's unsafe? You usually have to do something pretty bad to get an undef in the first place. Since IEEE-754 doesn't

Well in IEEE-754 Nan + any value returns Nan, so doing Nan + undef -> undef is wrong. I agree that undef are usually the results of a bad application behavior I'm just wondering what is the right thing to do. Thomas -----Original Message----- From: Tim Northover [mailto:t.p.northover at gmail.com] Sent: Wednesday, December 11, 2013 12:15 PM To: Raoux, Thomas F Cc: Philip Reames; llvmdev

On Dec 11, 2013, at 12:33 PM, Tim Northover <t.p.northover at gmail.com> wrote: > On 11 December 2013 20:25, Raoux, Thomas F <thomas.f.raoux at intel.com> wrote: >> Well in IEEE-754 Nan + any value returns Nan, so doing Nan + undef -> undef is wrong. > > I see what you mean having re-read the language reference. It looks > like LLVM's "undef" has to

On 11 December 2013 20:25, Raoux, Thomas F <thomas.f.raoux at intel.com> wrote: > Well in IEEE-754 Nan + any value returns Nan, so doing Nan + undef -> undef is wrong. I see what you mean having re-read the language reference. It looks like LLVM's "undef" has to be *some* bitpattern at any point, and that allows IEEE room to come in and say what the result is. Tim.

On 12/14/2013 05:18 PM, Dan Gohman wrote: > On Thu, Dec 12, 2013 at 5:43 PM, Owen Anderson <resistor at mac.com > <mailto:resistor at mac.com>> wrote: > > > On Dec 12, 2013, at 4:57 PM, Philip Reames > <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote: > >> undef + any == NaN (since undef can be NaN) or undef +

On Sun, Dec 15, 2013 at 5:12 PM, Philip Reames <listmail at philipreames.com>wrote: > On 12/14/2013 05:18 PM, Dan Gohman wrote: > >> On Thu, Dec 12, 2013 at 5:43 PM, Owen Anderson <resistor at mac.com >> <mailto:resistor at mac.com>> wrote: >> >> >> On Dec 12, 2013, at 4:57 PM, Philip Reames >> <listmail at philipreames.com

On 12/11/13 12:40 PM, Owen Anderson wrote: > > On Dec 11, 2013, at 12:33 PM, Tim Northover <t.p.northover at gmail.com > <mailto:t.p.northover at gmail.com>> wrote: > >> On 11 December 2013 20:25, Raoux, Thomas F <thomas.f.raoux at intel.com >> <mailto:thomas.f.raoux at intel.com>> wrote: >>> Well in IEEE-754 Nan + any value returns Nan,

Hi, When I run opt on the following LLVM IR: define i32 @foo() { bb0: %0 = bitcast i32 2139171423 to float %1 = insertelement <1 x float> undef, float %0, i32 0 %2 = extractelement <1 x float> %1, i32 0 %3 = bitcast float %2 to i32 ret i32 %3 } -> It generates: define i32 @foo() { bb0: ret i32 2143365727 } While tracking the value I see that the floating point value

On Thu, Dec 12, 2013 at 5:43 PM, Owen Anderson <resistor at mac.com> wrote: > > On Dec 12, 2013, at 4:57 PM, Philip Reames <listmail at philipreames.com> > wrote: > > undef + any == NaN (since undef can be NaN) or undef + any (since undef > could be zero) > > > undef + non-NaN is still undef. The compiler is free to choose any value > of the type it

Hi Oleg, On 01/09/14 18:46, Oleg Ranevskyy wrote: > Hi Duncan, > > I looked through the IEEE standard and here is what I found: > > *6.2 Operations with NaNs* > /"For an operation with quiet NaN inputs, other than maximum and minimum > operations, if a floating-point result is to be delivered the result shall be a > quiet NaN which should be one of the input

On Dec 12, 2013, at 4:57 PM, Philip Reames <listmail at philipreames.com> wrote: > undef + any == NaN (since undef can be NaN) or undef + any (since undef could be zero) undef + non-NaN is still undef. The compiler is free to choose any value of the type it wishes when simplifying an undef expression. The important point is that it still has to be a value of that type. Hence,

As far as I know, LLVM does not try very hard to guarantee constant folded NaN payloads that match exactly what the target would generate. —Owen > On Sep 16, 2014, at 10:30 AM, Oleg Ranevskyy <llvm.mail.list at gmail.com> wrote: > > Hi Duncan, > > I reread everything we've discussed so far and would like to pay closer attention to the the ARM's FPSCR register

Hi, Thank you for all your helpful comments. To sum up, below is the list of correct folding examples for fadd: (1) fadd %x, -0.0 -> %x (2) fadd undef, undef -> undef (3) fadd %x, undef -> NaN (undef is a NaN which is propagated) Looking through the code I found the "NoNaNs" flag accessed through an instance of

Hi Duncan, On 17.09.2014 21:10, Duncan Sands wrote: > Hi Oleg, > > On 17/09/14 18:45, Oleg Ranevskyy wrote: >> Hi, >> >> Thank you for all your helpful comments. >> >> To sum up, below is the list of correct folding examples for fadd: >> (1) fadd %x, -0.0 -> %x >> (2) fadd undef, undef -> undef

Hi Oleg, On 01/09/14 15:42, Oleg Ranevskyy wrote: > Hi, > > Thank you for your comment, Owen. > My LLVM expertise is certainly not enough to make such decisions yet. > Duncan, do you have any comments on this or do you know anyone else who can > decide about preserving NaN payloads? my take is that the first thing to do is to see what the IEEE standard says about NaNs.

Ha here is what I was missing. Thanks Jon. It still seems to me that the transformation of LLVM IR is invalid is that right? I assume we shouldn't be converting APFloat to float in order to avoid such problems? -----Original Message----- From: Jonathan Roelofs [mailto:jonathan at codesourcery.com] Sent: Wednesday, January 14, 2015 9:39 AM To: Raoux, Thomas F; LLVM Developers Mailing List

Yes, if %x is a NaN, we should expect that NaN is propagated. I'm still not sure what to do here. We can take comfort in knowing that whatever we do is likely an improvement over the current situation though. :) That's because the code in InstSimplify is inconsistent with the LangRef: http://llvm.org/docs/LangRef.html#undefined-values (UB for fdiv by 0?) ...and both of those are