On Mon, Aug 13, 2012 at 9:50 PM, Richard Henderson <r...@redhat.com> wrote: > On 08/13/2012 12:33 PM, Uros Bizjak wrote: >> AFAIU fma3 is better than fma4 for bdver2 (the only CPU that >> implements both FMA sets). Current description of bdver2 doesn't even >> enable fma4 in processor_alias_table due to this fact. >> >> The change you are referring to adds preference for fma3 insn set for >> generic code (not FMA4 builtins!), even when fma4 is enabled. So, no >> matter which combination and sequence of -mfmfa -mfma4 or -mxop user >> passes to the compiler, only fma3 instructions will be generated. > > This rationale needs to appear as a comment above > >> + (eq_attr "isa" "fma4") >> + (symbol_ref "TARGET_FMA4 && !TARGET_FMA")
I plan to commit following patch: --cut here-- Index: i386.md =================================================================== --- i386.md (revision 190362) +++ i386.md (working copy) @@ -659,6 +659,9 @@ (eq_attr "isa" "noavx2") (symbol_ref "!TARGET_AVX2") (eq_attr "isa" "bmi2") (symbol_ref "TARGET_BMI2") (eq_attr "isa" "fma") (symbol_ref "TARGET_FMA") + ;; Disable generation of FMA4 instructions for generic code + ;; since FMA3 is preferred for targets that implement both + ;; instruction sets. (eq_attr "isa" "fma4") (symbol_ref "TARGET_FMA4 && !TARGET_FMA") ] --cut here-- > Longer term we may well require some sort of > > (TARGET_FMA4 && !(TARGET_FMA && TARGET_PREFER_FMA3)) > > with an appropriate entry in ix86_tune_features to match. This won't work, since we have to prefer FMA3 also in case when only "-mfma -mfma4" without -mtune=XX is used. We can add TARGET_FMA_BOTH though, but I doubt there will ever be target that implements both insn sets without preferences. Uros.