[LLVMdev] Float undef value propagation

[Hal Finkel]

----- 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