https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102819
Bug ID: 102819 Summary: [11/12 Regression] IFN_COMPLEX_MUL matches things that it shouldn't Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rsandifo at gcc dot gnu.org CC: tnfchris at gcc dot gnu.org Target Milestone: --- Created attachment 51625 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51625&action=edit Examples of correct and incorrect matches complex_mul_pattern::matches() seems to accept too much. IIUC, for the non-conjugate case, it matches if: * the root is an interleaving of a SUB node and an ADD node * the children of the ADD node are two multiplications * the left-hand multiplication includes an EVEN/EVEN permute (i.e. multiplication by real) However, for the non-conjugate case, there don't seem to be any checks for the contents of the right-hand multiplication or how they match up with the left-hand multiplication. The later code then drops one child of this right-hand node. (If we don't currently check that the SUB node has the same children as the ADD node then perhaps we should check that too. Now that we have general VEC_PERM_EXPR nodes, the children could in principle be different.) With -O3 -march=armv8.2-a+sve, all of the functions in the attached test are recognised as complex multiplications, even though only good1 and good2 really are. There are quite a few other cases in which we incorrectly match a COMPLEX_MUL but then bail out due to: Built SLP cancelled: all SLP instances support load/store-lanes (Perhaps we should have a --param to disable that load/store-lanes check?)