[LLVMdev] Float undef value propagation

[Raoux, Thomas F]

>Out of curosity, do we currently perform this transformation when -enable-unsafe-fp-math is specified (-ffast-math from Clang)?
> -Hal
Actually the example I sent was compiled with unsafe math and it doesn't happen
Thomas

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Hal Finkel
Sent: Tuesday, December 10, 2013 4:41 PM
To: Philip Reames
Cc: llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] Float undef value propagation

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

_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev