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

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

[rsandifo at gcc dot 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?)

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

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102819

Tamar Christina <tnfchris at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2021-10-18
     Ever confirmed|0                           |1
           Assignee|unassigned at gcc dot gnu.org      |tnfchris at gcc dot gnu.org

--- Comment #1 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
bad3 is fixed already by my local patch set, I will fix bad1 and bad2 next week
and cleanup a bit and make a patch for backport.

> (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.)

Already done in the new patches.

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

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102819

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
   Target Milestone|---                         |11.3

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Note the correctness fix also needs backporting.

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

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102819

--- Comment #3 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tamar Christina <tnfchris@gcc.gnu.org>:

https://gcc.gnu.org/g:55d83cdf23b5f284b4e0bd0a6d1af3d947b2e7c3

commit r12-6993-g55d83cdf23b5f284b4e0bd0a6d1af3d947b2e7c3
Author: Tamar Christina <tamar.christina@arm.com>
Date:   Wed Feb 2 10:39:03 2022 +0000

    vect: Simplify and extend the complex numbers validation routines.

    This patch boosts the analysis for complex mul,fma and fms in order to
ensure
    that it doesn't create an incorrect output.

    Essentially it adds an extra verification to check that the two nodes it's
going
    to combine do the same operations on compatible values.  The reason it
needs to
    do this is that if one computation differs from the other then with the
current
    implementation we have no way to deal with it since we have to remove the
    permute.

    When we can keep the permute around we can probably handle these by
unrolling.

    While implementing this since I have to do the traversal anyway I took
advantage
    of it by simplifying the code a bit.  Previously we would determine whether
    something is a conjugate and then try to figure out which conjugate it is
and
    then try to see if the permutes match what we expect.

    Now the code that does the traversal will detect this in one go and return
to us
    whether the operation is something that can be combined and whether a
conjugate
    is present.

    Secondly because it does this I can now simplify the checking code itself
to
    essentially just try to apply fixed patterns to each operation.

    The patterns represent the order operations should appear in. For instance
a
    complex MUL operation combines :

      Left 1 + Right 1
      Left 2 + Right 2

    with a permute on the nodes consisting of:

      { Even, Even } + { Odd, Odd  }
      { Even, Odd  } + { Odd, Even }

    By abstracting over these patterns the checking code becomes quite simple.

    As part of this I was checking the order of the operands which was left in
    "slp" order. as in, the same order they showed up in during SLP, which
means
    that the accumulator is first.  However it looks like I didn't document
this
    and the x86 optab was implemented assuming the same order as FMA, i.e. that
    the accumulator is last.

    I have this changed the order to match that of FMA and FMS which corrects
the
    x86 codegen and will update the Arm targets.  This has now also been
    documented.

    gcc/ChangeLog:

            PR tree-optimization/102819
            PR tree-optimization/103169
            * doc/md.texi: Update docs for cfms, cfma.
            * tree-data-ref.h (same_data_refs): Accept optional offset.
            * tree-vect-slp-patterns.cc (is_linear_load_p): Fix issue with
repeating
            patterns.
            (vect_normalize_conj_loc): Remove.
            (is_eq_or_top): Change to take two nodes.
            (enum _conj_status, compatible_complex_nodes_p,
            vect_validate_multiplication): New.
            (class complex_add_pattern, complex_add_pattern::matches,
            complex_add_pattern::recognize, class complex_mul_pattern,
            complex_mul_pattern::recognize, class complex_fms_pattern,
            complex_fms_pattern::recognize, class complex_operations_pattern,
            complex_operations_pattern::recognize, addsub_pattern::recognize):
Pass
            new cache.
            (complex_fms_pattern::matches, complex_mul_pattern::matches): Pass
new
            cache and use new validation code.
            * tree-vect-slp.cc (vect_match_slp_patterns_2,
vect_match_slp_patterns,
            vect_analyze_slp): Pass along cache.
            (compatible_calls_p): Expose.
            * tree-vectorizer.h (compatible_calls_p, slp_node_hash,
            slp_compat_nodes_map_t): New.
            (class vect_pattern): Update signatures include new cache.

    gcc/testsuite/ChangeLog:

            PR tree-optimization/102819
            PR tree-optimization/103169
            * g++.dg/vect/pr99149.cc: xfail for now.
            * gcc.dg/vect/complex/pr102819-1.c: New test.
            * gcc.dg/vect/complex/pr102819-2.c: New test.
            * gcc.dg/vect/complex/pr102819-3.c: New test.
            * gcc.dg/vect/complex/pr102819-4.c: New test.
            * gcc.dg/vect/complex/pr102819-5.c: New test.
            * gcc.dg/vect/complex/pr102819-6.c: New test.
            * gcc.dg/vect/complex/pr102819-7.c: New test.
            * gcc.dg/vect/complex/pr102819-8.c: New test.
            * gcc.dg/vect/complex/pr102819-9.c: New test.
            * gcc.dg/vect/complex/pr103169.c: New test.

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

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102819

--- Comment #4 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tamar Christina <tnfchris@gcc.gnu.org>:

https://gcc.gnu.org/g:ab95fe61fea38fbac7f4e00abd32c2530532351a

commit r12-6994-gab95fe61fea38fbac7f4e00abd32c2530532351a
Author: Tamar Christina <tamar.christina@arm.com>
Date:   Wed Feb 2 10:51:38 2022 +0000

    AArch64: use canonical ordering for complex mul, fma and fms

    After the first patch in the series this updates the optabs to expect the
    canonical sequence.

    gcc/ChangeLog:

            PR tree-optimization/102819
            PR tree-optimization/103169
            * config/aarch64/aarch64-simd.md (cml<fcmac1><conj_op><mode>4): Use
            canonical order.
            * config/aarch64/aarch64-sve.md (cml<fcmac1><conj_op><mode>4):
Likewise.

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

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102819

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tamar Christina <tnfchris@gcc.gnu.org>:

https://gcc.gnu.org/g:9f6f411f63f3aceddd846e4b0d27202a6e13d42c

commit r12-6995-g9f6f411f63f3aceddd846e4b0d27202a6e13d42c
Author: Tamar Christina <tamar.christina@arm.com>
Date:   Wed Feb 2 10:52:17 2022 +0000

    AArch32: use canonical ordering for complex mul, fma and fms

    After the first patch in the series this updates the optabs to expect the
    canonical sequence.

    gcc/ChangeLog:

            PR tree-optimization/102819
            PR tree-optimization/103169
            * config/arm/vec-common.md (cml<fcmac1><conj_op><mode>4): Use
            canonical order.

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

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102819

Tamar Christina <tnfchris at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[11/12 Regression]          |[11 Regression]
                   |IFN_COMPLEX_MUL matches     |IFN_COMPLEX_MUL matches
                   |things that it shouldn't    |things that it shouldn't

--- Comment #6 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
fixed on master, will backport after a few days stew.

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

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102819

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Tamar Christina
<tnfchris@gcc.gnu.org>:

https://gcc.gnu.org/g:876e7c7f0fe47bae7c1922e2683ccb5e6e3ec9fe

commit r11-9621-g876e7c7f0fe47bae7c1922e2683ccb5e6e3ec9fe
Author: Tamar Christina <tamar.christina@arm.com>
Date:   Fri Feb 25 11:59:32 2022 +0000

    vect: Simplify and extend the complex numbers validation routines. (GCC-11
Backport)

    This is a backport of the GCC 12 patch backporting only the correctness
part of
    the fix.   This also backports two small helper functions and documentation
    update on the optabs.

    The patch boosts the analysis for complex mul,fma and fms in order to
ensure
    that it doesn't create an incorrect output.

    Essentially it adds an extra verification to check that the two nodes it's
going
    to combine do the same operations on compatible values.  The reason it
needs to
    do this is that if one computation differs from the other then with the
current
    implementation we have no way to deal with it since we have to remove the
    permute.

    When we can keep the permute around we can probably handle these by
unrolling.

    While implementing this since I have to do the traversal anyway I took
advantage
    of it by simplifying the code a bit.  Previously we would determine whether
    something is a conjugate and then try to figure out which conjugate it is
and
    then try to see if the permutes match what we expect.

    Now the code that does the traversal will detect this in one go and return
to us
    whether the operation is something that can be combined and whether a
conjugate
    is present.

    Secondly because it does this I can now simplify the checking code itself
to
    essentially just try to apply fixed patterns to each operation.

    The patterns represent the order operations should appear in. For instance
a
    complex MUL operation combines :

      Left 1 + Right 1
      Left 2 + Right 2

    with a permute on the nodes consisting of:

      { Even, Even } + { Odd, Odd  }
      { Even, Odd  } + { Odd, Even }

    By abstracting over these patterns the checking code becomes quite simple.

    As part of this I was checking the order of the operands which was left in
    "slp" order. as in, the same order they showed up in during SLP, which
means
    that the accumulator is first.  However it looks like I didn't document
this.

    gcc/ChangeLog:

            PR tree-optimization/102819
            PR tree-optimization/103169
            * gimple.h (gimple_num_args, gimple_arg): New.
            * doc/md.texi: Update docs for cfms, cfma.
            * tree-data-ref.h (same_data_refs): Accept optional offset.
            * tree-vect-slp-patterns.c (is_linear_load_p): Fix issue with
repeating
            patterns.
            (vect_normalize_conj_loc): Remove.
            (is_eq_or_top): Change to take two nodes.
            (enum _conj_status, compatible_complex_nodes_p,
            vect_validate_multiplication): New.
            (class complex_add_pattern, complex_add_pattern::matches,
            complex_add_pattern::recognize, class complex_mul_pattern,
            complex_mul_pattern::recognize, class complex_fms_pattern,
            complex_fms_pattern::recognize,, class complex_fma_pattern,
            complex_fma_pattern::recognize, class complex_operations_pattern,
            complex_operations_pattern::recognize, addsub_pattern::recognize):
Pass
            new cache.
            (complex_fms_pattern::matches, complex_fma_pattern::matches,
            complex_mul_pattern::matches): Pass new cache and use new
validation
            code.
            * tree-vect-slp.c (vect_match_slp_patterns_2,
vect_match_slp_patterns,
            vect_analyze_slp): Pass along cache.
            (compatible_calls_p): Expose.
            * tree-vectorizer.h (compatible_calls_p, slp_node_hash,
            slp_compat_nodes_map_t): New.
            (class vect_pattern): Update signatures include new cache.

    gcc/testsuite/ChangeLog:

            PR tree-optimization/102819
            PR tree-optimization/103169
            * g++.dg/vect/pr99149.cc: xfail for now.
            * gcc.dg/vect/complex/pr102819-1.c: New test.
            * gcc.dg/vect/complex/pr102819-2.c: New test.
            * gcc.dg/vect/complex/pr102819-3.c: New test.
            * gcc.dg/vect/complex/pr102819-4.c: New test.
            * gcc.dg/vect/complex/pr102819-5.c: New test.
            * gcc.dg/vect/complex/pr102819-6.c: New test.
            * gcc.dg/vect/complex/pr102819-7.c: New test.
            * gcc.dg/vect/complex/pr102819-8.c: New test.
            * gcc.dg/vect/complex/pr102819-9.c: New test.
            * gcc.dg/vect/complex/pr103169.c: New test.

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

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102819

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Tamar Christina
<tnfchris@gcc.gnu.org>:

https://gcc.gnu.org/g:6bb338eab3debf7742b1455146dd556b3ce3737c

commit r11-9622-g6bb338eab3debf7742b1455146dd556b3ce3737c
Author: Tamar Christina <tamar.christina@arm.com>
Date:   Fri Feb 25 12:00:11 2022 +0000

    AArch64: use canonical ordering for complex mul, fma and fms

    After the first patch in the series this updates the optabs to expect the
    canonical sequence.

    gcc/ChangeLog:

            PR tree-optimization/102819
            PR tree-optimization/103169
            * config/aarch64/aarch64-simd.md (cml<fcmac1><conj_op><mode>4): Use
            canonical order.
            * config/aarch64/aarch64-sve.md (cml<fcmac1><conj_op><mode>4):
Likewise.

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

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102819

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Tamar Christina
<tnfchris@gcc.gnu.org>:

https://gcc.gnu.org/g:7d713d56ec32b8c7101066619b4852b797955e24

commit r11-9623-g7d713d56ec32b8c7101066619b4852b797955e24
Author: Tamar Christina <tamar.christina@arm.com>
Date:   Fri Feb 25 12:00:46 2022 +0000

    AArch32: use canonical ordering for complex mul, fma and fms

    After the first patch in the series this updates the optabs to expect the
    canonical sequence.

    gcc/ChangeLog:

            PR tree-optimization/102819
            PR tree-optimization/103169
            * config/arm/vec-common.md (cml<fcmac1><conj_op><mode>4): Use
            canonical order.

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

[tnfchris at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102819

Tamar Christina <tnfchris at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #10 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
fixed in all affected branches.