https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126932
--- Comment #5 from Drea Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #4)
> So do we know how/why x86 is avoiding this. The only reference I see to the
> fp contract in the x86 backend is in the vector costing model.
x86 and aarch64 both use the `fma` rtl rather than `(plus (mult ...) ...)` to
represent the fused multiply add set of instructions even for vectors.
e.g aarch64-simd.md:
```
(define_insn "fma<mode>4<vczle><vczbe>"
[(set (match_operand:VHSDF 0 "register_operand" "=w")
(fma:VHSDF (match_operand:VHSDF 1 "register_operand" "w")
(match_operand:VHSDF 2 "register_operand" "w")
(match_operand:VHSDF 3 "register_operand" "0")))]
"TARGET_SIMD"
"fmla\\t%0.<Vtype>, %1.<Vtype>, %2.<Vtype>"
[(set_attr "type" "neon_fp_mla_<stype><q>")]
)
```
or i386/sse.md:
```
(define_expand "fma<mode>4"
[(set (match_operand:FMAMODEM 0 "register_operand")
(fma:FMAMODEM
(match_operand:FMAMODEM 1 "nonimmediate_operand")
(match_operand:FMAMODEM 2 "nonimmediate_operand")
(match_operand:FMAMODEM 3 "nonimmediate_operand")))])
...
(define_insn "*fma_fmadd_<mode>"
[(set (match_operand:FMAMODE 0 "register_operand" "=v,v,v,x,x")
(fma:FMAMODE
(match_operand:FMAMODE 1 "nonimmediate_operand" "%0,0,v,x,x")
(match_operand:FMAMODE 2 "nonimmediate_operand" "vm,v,vm,x,jm")
(match_operand:FMAMODE 3 "nonimmediate_operand" "v,vm,0,xjm,x")))]
"TARGET_FMA || TARGET_FMA4"
"@
vfmadd132<ssemodesuffix>\t{%2, %3, %0|%0, %3, %2}
vfmadd213<ssemodesuffix>\t{%3, %2, %0|%0, %2, %3}
vfmadd231<ssemodesuffix>\t{%2, %1, %0|%0, %1, %2}
vfmadd<ssemodesuffix>\t{%3, %2, %1, %0|%0, %1, %2, %3}
vfmadd<ssemodesuffix>\t{%3, %2, %1, %0|%0, %1, %2, %3}"
[(set_attr "isa" "fma,fma,fma,fma4,fma4")
(set_attr "type" "ssemuladd")
(set_attr "addr" "*,*,*,gpr16,gpr16")
(set_attr "mode" "<MODE>")])
```
