https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109052
--- Comment #5 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Vladimir Makarov from comment #4)
> So I think the current patch is probably an adequate solution.
Perhaps the compiler should also try to swap input operands to fit the combined
insn when commutative operands are allowed. This would solve the testcase from
Comment #2:
double foo (double a, double b)
{
double z = __builtin_fmod (a, 3.14);
return z * b;
}
gcc -O2 -mfpmath=both -mavx:
Failed combined insn:
24: r90:DF=r96:DF*r85:DF
REG_DEAD r85:DF
REG_DEAD r82:DF
Restoring insn after failed combining:
(^^^ shouldn't there be a memory operand mentioned in the above RTX dump?)
...
(insn 42 41 24 6 (set (reg/v:DF 23 xmm3 [orig:82 z ] [82])
(mem/c:DF (plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8])) [1 %sfp+-24 S8 A64])) "fmod.c":4:12 145
{*movdf_internal}
(nil))
(insn 24 42 30 6 (set (reg:DF 20 xmm0 [90])
(mult:DF (reg/v:DF 23 xmm3 [orig:82 z ] [82])
(reg/v:DF 22 xmm2 [orig:85 b ] [85]))) "fmod.c":4:12 1189
{*fop_df_comm}
(nil))
...
As can be seen in the above dump, swapped input operands would fit alternative
(v,v,vm) in the insn pattern:
[(set (match_operand:MODEF 0 "register_operand" "=f,x,v")
(match_operator:MODEF 3 "binary_fp_operator"
[(match_operand:MODEF 1 "nonimmediate_operand" "%0,0,v")
(match_operand:MODEF 2 "nonimmediate_operand" "fm,xm,vm")]))]
