[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