[Bug tree-optimization/102819] New: [11/12 Regression] IFN_COMPLEX_MUL matches things that it shouldn't

["rsandifo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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?)