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:
; Function Attrs: nounwind
define float @_Z1fv() #0 {
entry:
ret float fadd (float undef, float 2.000000e+00)
}
Is it safe to transform "%add = fadd fast float undef, 2.000000e+00"
to "undef"? Is there a reason why constant propagation pass
doesn't do this transformation?
Thanks,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131209/881d8c55/attachment.html>
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: > > ; Function Attrs: nounwind > > define float @_Z1fv() #0 { > > entry: > > ret float fadd (float undef, float 2.000000e+00) > > } > > Is it safe to transform "%add = fadd fast float undef, 2.000000e+00" > to "undef"? Is there a reason why constant propagation pass doesn't do > this transformation? >I'm not totally sure this is safe. Not saying it isn't, but the wording around undef and bit patterns in the language spec is concerning me. Could there be a case where some bit of the result is known given only one constant argument? I'm not familiar enough with the floating point semantics of LLVM's IR, but suspect there might be such a case. A few cases worth thinking about: undef + max_float, undef + NAN (signaling or non-signalling). If someone more familiar with floating point knows better, please feel free to chime in. On the other hand, the following transformation is definitely safe: define float @_Z1fv() #0 { entry: ret 2.000000e+00 } (undef could be zero, thus result of the add is the second argument) If we don't apply that transform, we probably should. (Well, assuming there's not some normalization/rounding trap here. I don't *think* there is, but I'm not totally sure.) Yours, Philip -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131210/d3d3716a/attachment.html>
----- 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 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: > > > > ; Function Attrs: nounwind > > define float @_Z1fv() #0 { > > entry: > > ret float fadd (float undef, float 2.000000e+00) > > } > > > > Is it safe to transform “%add = fadd fast float undef, 2.000000e+00” > to “undef”? Is there a reason why constant propagation pass doesn’t > do this transformation? I'm not totally sure this is safe. Not > saying it isn't, but the wording around undef and bit patterns in > the language spec is concerning me. Could there be a case where some > bit of the result is known given only one constant argument? I'm not > familiar enough with the floating point semantics of LLVM's IR, but > suspect there might be such a case. A few cases worth thinking > about: undef + max_float, undef + NAN (signaling or non-signalling). > If someone more familiar with floating point knows better, please > feel free to chime in.Out of curosity, do we currently perform this transformation when -enable-unsafe-fp-math is specified (-ffast-math from Clang)? -Hal> > On the other hand, the following transformation is definitely safe: > > > define float @_Z1fv() #0 { > > entry: > > ret 2.000000e+00 } > (undef could be zero, thus result of the add is the second argument) > > If we don't apply that transform, we probably should. (Well, assuming > there's not some normalization/rounding trap here. I don't *think* > there is, but I'm not totally sure.) > > Yours, > Philip > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >-- Hal Finkel Assistant Computational Scientist Leadership Computing Facility Argonne National Laboratory
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 keep some arithmetic constant expressions while those could always
be evaluated as far as I understand (unless it uses global pointers)?
In this example there might be cases where we would be able to propagate undef
which could generate better code.
Thanks,
Thomas
From: llvmdev-bounces at cs.uiuc.edu<mailto:llvmdev-bounces at
cs.uiuc.edu> [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Philip
Reames
Sent: Tuesday, December 10, 2013 12:56 PM
To: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>
Subject: Re: [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:
; Function Attrs: nounwind
define float @_Z1fv() #0 {
entry:
ret float fadd (float undef, float 2.000000e+00)
}
Is it safe to transform "%add = fadd fast float undef, 2.000000e+00"
to "undef"? Is there a reason why constant propagation pass
doesn't do this transformation?
I'm not totally sure this is safe. Not saying it isn't, but the wording
around undef and bit patterns in the language spec is concerning me. Could
there be a case where some bit of the result is known given only one constant
argument? I'm not familiar enough with the floating point semantics of
LLVM's IR, but suspect there might be such a case. A few cases worth
thinking about: undef + max_float, undef + NAN (signaling or non-signalling).
If someone more familiar with floating point knows better, please feel free to
chime in.
On the other hand, the following transformation is definitely safe:
define float @_Z1fv() #0 {
entry:
ret 2.000000e+00
}
(undef could be zero, thus result of the add is the second argument)
If we don't apply that transform, we probably should. (Well, assuming
there's not some normalization/rounding trap here. I don't *think*
there is, but I'm not totally sure.)
Yours,
Philip
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131211/8a83434c/attachment.html>
Hi! Am 09.12.2013 23:13, schrieb Raoux, Thomas F:> Is it safe to transform “%add = fadd fast float undef, 2.000000e+00” to > “undef”?http://llvm.org/docs/LangRef.html#fastmath "fast" implies "nnan" which means the result is undefined if any argument is NaN. Since undef could be NaN, I guess the transformation is safe. Regards, Tobias