[PATCH] D4583: don't transform splats of vector FP (PR20358)

[hfinkel@anl.gov via llvm-commits]

hfinkel added a comment.

In http://reviews.llvm.org/D4583#294643, @spatel wrote:

> I just connected the dots between this case and other recent speculative execution bugs/patches:
>  https://llvm.org/bugs/show_bug.cgi?id=24343
>  https://llvm.org/bugs/show_bug.cgi?id=24818
>  https://llvm.org/bugs/show_bug.cgi?id=25572
>  http://reviews.llvm.org/D12882
>  http://reviews.llvm.org/D13297
>  http://reviews.llvm.org/D14630
>
> This splat is just a special (and probably extremely rare) case of the general problem:
>
>   #define DENORM ((float)(1.0e-39))
>   float foo(float x, float y) {
>      if (x > DENORM) return x * y;
>      else return y;
>   }
>
> $ ./clang -O2 denorm.c -S -o - -emit-llvm
>
>   define float @foo(float %x, float %y) #0 {
>     %cmp = fcmp ogt float %x, 0x37D5C73000000000
>     %mul = fmul float %x, %y    <--- crazy expensive op that we wanted to avoid just got executed
>     %retval.0 = select i1 %cmp, float %mul, float %y
>     ret float %retval.0
>   }
>   
>
> Unless there is objection, I'll abandon this patch. If we really want to solve this, we'd have to add some global flag (-fno-speculative-fp-math?) or instruction-level annotation to include FP ops under !isSafeToSpeculativelyExecute().


I agree. Also, this seems related to Sergey Dmitrouk's work on enabling FP env access, etc.


http://reviews.llvm.org/D4583