[PATCH] D26855: New unsafe-fp-math implementation for X86 target

Andrew V. Tischenko via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Feb 3 03:03:58 PST 2017


avt77 added inline comments.


================
Comment at: lib/CodeGen/SelectionDAG/DAGCombiner.cpp:15331
+  case Triple::x86_64:
+    return SDValue();
+  }
----------------
guyblank wrote:
> avt77 wrote:
> > guyblank wrote:
> > > sorry for joining the discussion so late.
> > > 
> > > IIUC this affects all X86 CPUs, but I didn't see handling for all possible types (as stated in a TODO below).
> > > 
> > > specifically, does this affect AVX-512 code?
> > At the moment we support only limited set of types (see X86InstrInfo::genAlternativeCodeSequence below) but we are ready to extend it if it is necessary.
> you support the machine combiner approach for a limited set of types/instructions, but you've disabled the DAG combine approach for **ALL ** types/instructions.
> 
> I ran CodeGen/X86/recip-fastmath.ll on knl with your changes.
> the output for @f32_one_step (for example) changed from 
> 
> vrcp14ss    %xmm0, %xmm0, %xmm1
> vfnmadd213ss    .LCPI1_0(%rip), %xmm1, %xmm0
> vfmadd132ss %xmm1, %xmm1, %xmm0
> 
> to
> vmovss  .LCPI1_0(%rip), %xmm1
> vdivss  %xmm0, %xmm1, %xmm0
> 
> 
I did not do anything with knl and as result you are right: this code generation was lost. Do you know other examples like that? If the problem in knl only then I could easily support it. But of course I could add special option like "-use_machine-combiner" or "-use-dag-combiner". What's better?


https://reviews.llvm.org/D26855





More information about the llvm-commits mailing list