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 at cs.uiuc.edu Subject: Re: [LLVMdev] Float undef value propagation 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 have that concept I can't see how it could have anything to say on how LLVM optimises it. Cheers. Tim.
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 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 be *some* bitpattern at any point, and that > allows IEEE room to come in and say what the result is.To generalize this, undef can be any bit pattern, but it still has to respect universal constraints of its type. This means that predicates that are true for all values of a type must also be true for undef. Because NaN + x == NaN is true for all values of x, it must also be true for undef. —Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131211/3a663359/attachment.html>