[LLVMdev] Float undef value propagation

[Philip Reames]

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>