On Mon, Sep 20, 2021 at 5:15 AM Richard Biener via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> This allows vectorization (in practice non-loop vectorization) to
> have a stmt participate in different vector type vectorizations.
> It allows us to remove vect_update_shared_vectype and replace it
> by pushing/popping STMT_VINFO_VECTYPE from SLP_TREE_VECTYPE around
> vect_analyze_stmt and vect_transform_stmt.
>
> For data-ref the situation is a bit more complicated since we
> analyze alignment info with a specific vector type in mind which
> doesn't play well when that changes.
>
> So the bulk of the change is passing down the actual vector type
> used for a vectorized access to the various accessors of alignment
> info, first and foremost dr_misalignment but also aligned_access_p,
> known_alignment_for_access_p, vect_known_alignment_in_bytes and
> vect_supportable_dr_alignment. I took the liberty to replace
> ALL_CAPS macro accessors with the lower-case function invocations.
>
> The actual changes to the behavior are in dr_misalignment which now
> is the place factoring in the negative step adjustment as well as
> handling alignment queries for a vector type with bigger alignment
> requirements than what we can (or have) analyze(d).
>
> vect_slp_analyze_node_alignment makes use of this and upon receiving
> a vector type with a bigger alingment desire re-analyzes the DR
> with respect to it but keeps an older more precise result if possible.
> In this context it might be possible to do the analysis just once
> but instead of analyzing with respect to a specific desired alignment
> look for the biggest alignment we can compute a not unknown alignment.
>
> The ChangeLog includes the functional changes but not the bulk due
> to the alignment accessor API changes - I hope that's something good.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, testing on SPEC
> CPU 2017 in progress (for stats and correctness).
>
> Any comments?
>
> Thanks,
> Richard.
>
> 2021-09-17 Richard Biener <rguent...@suse.de>
>
> PR tree-optimization/97351
> PR tree-optimization/97352
> PR tree-optimization/82426
> * tree-vectorizer.h (dr_misalignment): Add vector type
> argument.
> (aligned_access_p): Likewise.
> (known_alignment_for_access_p): Likewise.
> (vect_supportable_dr_alignment): Likewise.
> (vect_known_alignment_in_bytes): Likewise. Refactor.
> (DR_MISALIGNMENT): Remove.
> (vect_update_shared_vectype): Likewise.
> * tree-vect-data-refs.c (dr_misalignment): Refactor, handle
> a vector type with larger alignment requirement and apply
> the negative step adjustment here.
> (vect_calculate_target_alignment): Remove.
> (vect_compute_data_ref_alignment): Get explicit vector type
> argument, do not apply a negative step alignment adjustment
> here.
> (vect_slp_analyze_node_alignment): Re-analyze alignment
> when we re-visit the DR with a bigger desired alignment but
> keep more precise results from smaller alignments.
> * tree-vect-slp.c (vect_update_shared_vectype): Remove.
> (vect_slp_analyze_node_operations_1): Do not update the
> shared vector type on stmts.
> * tree-vect-stmts.c (vect_analyze_stmt): Push/pop the
> vector type of an SLP node to the representative stmt-info.
> (vect_transform_stmt): Likewise.
>
> * gcc.target/i386/vect-pr82426.c: New testcase.
> * gcc.target/i386/vect-pr97352.c: Likewise.
> ---
> gcc/testsuite/gcc.target/i386/vect-pr82426.c | 32 +++
> gcc/testsuite/gcc.target/i386/vect-pr97352.c | 22 ++
> gcc/tree-vect-data-refs.c | 217 ++++++++++---------
> gcc/tree-vect-slp.c | 59 -----
> gcc/tree-vect-stmts.c | 77 ++++---
> gcc/tree-vectorizer.h | 32 ++-
> 6 files changed, 231 insertions(+), 208 deletions(-)
> create mode 100644 gcc/testsuite/gcc.target/i386/vect-pr82426.c
> create mode 100644 gcc/testsuite/gcc.target/i386/vect-pr97352.c
>
> diff --git a/gcc/testsuite/gcc.target/i386/vect-pr82426.c
> b/gcc/testsuite/gcc.target/i386/vect-pr82426.c
> new file mode 100644
> index 00000000000..741a1d14d36
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/vect-pr82426.c
> @@ -0,0 +1,32 @@
> +/* i?86 does not have V2SF, x32 does though. */
> +/* { dg-do compile { target { lp64 || x32 } } } */
It should be target { ! ia32 }
> +/* ??? With AVX512 we only realize one FMA opportunity. */
Hongtao, is AVX512 missing 64-bit vector support??
> +/* { dg-options "-O3 -mavx -mfma -mno-avx512f" } */
> +
> +struct Matrix
> +{
> + float m11;
> + float m12;
> + float m21;
> + float m22;
> + float dx;
> + float dy;
> +};
> +
> +struct Matrix multiply(const struct Matrix *a, const struct Matrix *b)
> +{
> + struct Matrix out;
> + out.m11 = a->m11*b->m11 + a->m12*b->m21;
> + out.m12 = a->m11*b->m12 + a->m12*b->m22;
> + out.m21 = a->m21*b->m11 + a->m22*b->m21;
> + out.m22 = a->m21*b->m12 + a->m22*b->m22;
> +
> + out.dx = a->dx*b->m11 + a->dy*b->m21 + b->dx;
> + out.dy = a->dx*b->m12 + a->dy*b->m22 + b->dy;
> + return out;
> +}
> +
> +/* The whole kernel should be vectorized with V4SF and V2SF operations. */
> +/* { dg-final { scan-assembler-times "vadd" 1 } } */
> +/* { dg-final { scan-assembler-times "vmul" 2 } } */
> +/* { dg-final { scan-assembler-times "vfma" 2 } } */
--
H.J.
