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 + 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, predicates that are true for /any/ choice of value > must still be respected. This is the case for NaN + undef == NaN: > while the compiler is free to choose any value for the undef, there > is no such value for which the result is not NaN. > > > undef + non-NaN is not undef. This is because while you can pick any > value for the original undef, if you leave an undef behind, you can't > control what someone else might pick for it. There are floating-point > values which cannot be the result of undef + non-NaN for many values of > non-NaN, so the result of undef + non-Nan is not an unconstrained undef.This is a very good point. Does this mean that the only valid transformations of "undef + Constant" are "Constant" (by undef == 0) or "NaN" (by undef == NaN)? Or are there known easily describible subsets of Constants which allow a more general transform? As an example, when Constant == 0, it would appear that propagating the undef is fine. (I think.) Are there other cases like this? Or am I wrong about the legality of this example? Philip
For every non-NaN, non-Inf constant C, C + (-C) = 0, right? So I guess you could also take undef = -C, and get 0. I'm not sure whether you can do the same for multiplication (taking undef = 1/C and getting 1), though. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Philip Reames Sent: Monday, December 16, 2013 03:12 To: Dan Gohman; Owen Anderson Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Float undef value propagation 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 + 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, predicates that are true for /any/ choice of value > must still be respected. This is the case for NaN + undef == NaN: > while the compiler is free to choose any value for the undef, there > is no such value for which the result is not NaN. > > > undef + non-NaN is not undef. This is because while you can pick any > value for the original undef, if you leave an undef behind, you can't > control what someone else might pick for it. There are floating-point > values which cannot be the result of undef + non-NaN for many values > of non-NaN, so the result of undef + non-Nan is not an unconstrained undef.This is a very good point. Does this mean that the only valid transformations of "undef + Constant" are "Constant" (by undef == 0) or "NaN" (by undef == NaN)? Or are there known easily describible subsets of Constants which allow a more general transform? As an example, when Constant == 0, it would appear that propagating the undef is fine. (I think.) Are there other cases like this? Or am I wrong about the legality of this example? Philip _______________________________________________ LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
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 <mailto: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, predicates that are true for /any/ choice of value >> >> must still be respected. This is the case for NaN + undef == NaN: >> while the compiler is free to choose any value for the undef, there >> is no such value for which the result is not NaN. >> >> >> undef + non-NaN is not undef. This is because while you can pick any >> value for the original undef, if you leave an undef behind, you can't >> control what someone else might pick for it. There are floating-point >> values which cannot be the result of undef + non-NaN for many values of >> non-NaN, so the result of undef + non-Nan is not an unconstrained undef. >> > This is a very good point. Does this mean that the only valid > transformations of "undef + Constant" are "Constant" (by undef == 0) or > "NaN" (by undef == NaN)? Or are there known easily describible subsets of > Constants which allow a more general transform? > > As an example, when Constant == 0, it would appear that propagating the > undef is fine. (I think.) Are there other cases like this? Or am I wrong > about the legality of this example?-0.0 is never the result of adding 0.0 to something, so even that isn't safe (outside of -ffast-math mode) Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131216/81d2ea7b/attachment.html>
On 12/16/13 1:19 PM, Dan Gohman wrote:> On Sun, Dec 15, 2013 at 5:12 PM, Philip Reames > <listmail at philipreames.com <mailto: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> > <mailto: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> > <mailto:listmail at philipreames.com > <mailto: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, predicates that are true for /any/ choice of > value > > must still be respected. This is the case for NaN + undef > == NaN: > while the compiler is free to choose any value for the > undef, there > is no such value for which the result is not NaN. > > > undef + non-NaN is not undef. This is because while you can > pick any > value for the original undef, if you leave an undef behind, > you can't > control what someone else might pick for it. There are > floating-point > values which cannot be the result of undef + non-NaN for many > values of > non-NaN, so the result of undef + non-Nan is not an > unconstrained undef. > > This is a very good point. Does this mean that the only valid > transformations of "undef + Constant" are "Constant" (by undef => 0) or "NaN" (by undef == NaN)? Or are there known easily > describible subsets of Constants which allow a more general transform? > > As an example, when Constant == 0, it would appear that > propagating the undef is fine. (I think.) Are there other cases > like this? Or am I wrong about the legality of this example? > > > -0.0 is never the result of adding 0.0 to something, so even that > isn't safe (outside of -ffast-math mode)Dan, thank you for the clarification. Your responses have been very helpful in understanding corner cases. I think that we've identified a couple of transformations which would be worthwhile adding to SimplifyFAddInst. Would you agree? Here are the cases I'm considering: NaN + any == NaN undef + any == NaN (since undef can be NaN, can not legally propagate RHS) I believe based on our discussion that both of these are correct, even outside of fast-math. Do you agree? I'm happy to prepare a patch, but want to get agreement on the legality of the transformations first. Just to check my understand, the following is NOT legal: undef + undef = undef (since the output could be -0.0 which is not a legal outcome for an fadd) Yours, Philip -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131219/607b566c/attachment.html>