[Bug tree-optimization/98563] New: regression: vectorization fails while it worked on gcc 9 and earlier

[Bug tree-optimization/98563] New: regression: vectorization fails while it worked on gcc 9 and earlier

[nathanael.schaeffer at gmail dot com]

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

            Bug ID: 98563
           Summary: regression: vectorization fails while it worked on gcc
                    9 and earlier
           Product: gcc
           Version: 10.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: nathanael.schaeffer at gmail dot com
  Target Milestone: ---

I have found what seems to be a regression.

The following code is not compiled to 256-bit AVX when compiled with
-fopenmp-simd, while it is fully vectorized without!

Here are the resulting code with different options, with gcc 10.1:
-O3 -fopenmp-simd  => xmm
-O3                => ymm
-O3 -fopenmp-simd -fno-signed-zeros  => ymm

gcc 9 and earlier always vectorize to full-width (ymm)

#include <complex>
typedef std::complex<double> cplx;

void test(cplx* __restrict__ a, const cplx* b, double c, int N)
{
    #pragma omp simd
    for (int i=0; i<8*N; i++) {
        a[i] = c*(a[i]-b[i]);
    }
}

See the result on godbolt: https://godbolt.org/z/9ThqKE

Also, I discover that no avx512 code is generated for this loop. Is this
intended? Is there an option to enable avx512 vectorization?

[Bug tree-optimization/98563] regression: vectorization fails while it worked on gcc 9 and earlier

[nathanael.schaeffer at gmail dot com]

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

--- Comment #1 from N Schaeffer <nathanael.schaeffer at gmail dot com> ---
I just found the -mprefer-vector-width=512 to force to use zmm.
The reported regression however remains.

[Bug tree-optimization/98563] [10/11 Regression] vectorization fails while it worked on gcc 9 and earlier

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |10.3
             Status|UNCONFIRMED                 |NEW
             Target|                            |x86_64-*-* i?86-*-*
           Keywords|                            |missed-optimization, openmp
            Summary|regression: vectorization   |[10/11 Regression]
                   |fails while it worked on    |vectorization fails while
                   |gcc 9 and earlier           |it worked on gcc 9 and
                   |                            |earlier
           Priority|P3                          |P2
                 CC|                            |jakub at gcc dot gnu.org
             Blocks|                            |53947
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-01-07

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
So the issue is that GCC 9 was able to vectorize the loop while GCC 10 and
trunk are not but those vectorize the basic block (where there's only enough
data to use SSE).

> g++-10 t.C -march=skylake-avx512 -O3 -fopenmp-simd -fdump-tree-vect-details -S -fopt-info-vec
t.C:4:6: optimized: basic block part vectorized using 32 byte vectors
> g++-9 t.C -march=skylake-avx512 -O3 -fopenmp-simd -fdump-tree-vect-details -S -fopt-info-vec
t.C:8:26: optimized: loop vectorized using 32 byte vectors

the reason it fails is


Creating dr for REALPART_EXPR <D.49590[_13]._M_value>
analyze_innermost: t.C:4:6: missed:  failed: evolution of offset is not affine.
        base_address:
        offset from base address:
        constant offset from base address:
        step:
        base alignment: 0
        base misalignment: 0
        offset alignment: 0
        step alignment: 0
        base_object: D.49590
        Access function 0: 0
        Access function 1: 0
        Access function 2: scev_not_known;

where this is

  _13 = .GOMP_SIMD_LANE (simduid.0_12(D), 0);
  REALPART_EXPR <D.49590[_13]._M_value> = _26;
  IMAGPART_EXPR <D.49590[_13]._M_value> = _7;
  _20 = REALPART_EXPR <MEM <struct complex[64]> [(const struct complex
&)&D.49590][_13]._M_value>;

I'm not sure why this is here with GCC 10+ but not GCC 9.

Jakub?


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug tree-optimization/98563] [10/11 Regression] vectorization fails while it worked on gcc 9 and earlier

[nathanael.schaeffer at gmail dot com]

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

--- Comment #3 from N Schaeffer <nathanael.schaeffer at gmail dot com> ---
I'd like to add that when you say "vectorization of the basic block", the code
generated is actually worse than non-vectorized naive code: it handles all
loads and arithmetic operations in scalar mode (v*sd instructions) and packs
two values into xmm before storing...

[Bug tree-optimization/98563] [10/11 Regression] vectorization fails while it worked on gcc 9 and earlier since since r10-2271-gd81ab49d0586fca0

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[10/11 Regression]          |[10/11 Regression]
                   |vectorization fails while   |vectorization fails while
                   |it worked on gcc 9 and      |it worked on gcc 9 and
                   |earlier                     |earlier since since
                   |                            |r10-2271-gd81ab49d0586fca0
                 CC|                            |marxin at gcc dot gnu.org

--- Comment #4 from Martin Liška <marxin at gcc dot gnu.org> ---
It started with r10-2271-gd81ab49d0586fca0.

[Bug tree-optimization/98563] [10/11 Regression] vectorization fails while it worked on gcc 9 and earlier since since r10-2271-gd81ab49d0586fca0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jamborm at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That change included an important bugfix for the simd handling of addressable
locals, when they escape they would be then mishandled during vectorization.
I think the current representation is right, represent them as if each simd
lane has its own copy of the variable.
The reason why this isn't vectorized is I think PR91020, that SRA doesn't split
those real and imag parts as separate (simd array) vars.

[Bug tree-optimization/98563] [10/11 Regression] vectorization fails while it worked on gcc 9 and earlier since since r10-2271-gd81ab49d0586fca0

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #5)
> That change included an important bugfix for the simd handling of
> addressable locals, when they escape they would be then mishandled during
> vectorization.
> I think the current representation is right, represent them as if each simd
> lane has its own copy of the variable.
> The reason why this isn't vectorized is I think PR91020, that SRA doesn't
> split those real and imag parts as separate (simd array) vars.

Hmm, it's a bit far-fetched to consider this an SRA issue - can't OMP lowering
do any better here?

[Bug tree-optimization/98563] [10/11 Regression] vectorization fails while it worked on gcc 9 and earlier since since r10-2271-gd81ab49d0586fca0

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I'm afraid no.
The vectorization can handle addresses into the simd arrays, but right now only
if it accesses the whole element, i.e. when we can turn the simd array into a
vector register (or set thereof) that hold the variable.
In this case that is not the case, as in the end it uses the real and imag
parts separately.
So, either it can be handled in SRA, or we'd need to teach the vectorizer to
permute those fur us.

[Bug tree-optimization/98563] [10/11 Regression] vectorization fails while it worked on gcc 9 and earlier since since r10-2271-gd81ab49d0586fca0

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #7)
> I'm afraid no.
> The vectorization can handle addresses into the simd arrays, but right now
> only if it accesses the whole element, i.e. when we can turn the simd array
> into a vector register (or set thereof) that hold the variable.
> In this case that is not the case, as in the end it uses the real and imag
> parts separately.
> So, either it can be handled in SRA, or we'd need to teach the vectorizer to
> permute those fur us.

Hmm, I see.  The vectorizer can in theory handle "existing" vectors (currently
only enabled for basic-block SLP though).  But of course the first hurdle is
to not treat those as memory accesses (thus ignore the data-ref analysis
failure or somehow make that treat the SIMD_LANE indexing "nicely").

When we see

  _13 = .GOMP_SIMD_LANE (simduid.0_12(D), 0);

can we compute how _13 evolves with loop iteration?  Thus, can we
SCEV analyze it?  Isn't it sth like { .GOMP_SIMD_LANE_START (simduid.0_12(D),
.GOMP_SIMD_LANE_STEP (simduid.0_12(D), 0) } thus an affine evolution
in the end?

Simplified C testcase:

typedef _Complex double cplx;
void foo (cplx *);
void test(cplx* __restrict__ a, const cplx* b, double c, int N)
{
  cplx tem;
#pragma omp simd private (tem)
  for (int i=0; i<8*N; i++) {
      __real tem = __real b[i];
      __imag tem = __imag b[i];
      __real a[i] = __real tem;
      __imag a[i] = __imag tem;
  }
  foo (&tem);
}

which we miscompile (well, I guess I did sth wrong with the use after
the loop but to trigger GOMP_SIMD_LANE the temporary seems to need to
have its address taken).

[Bug tree-optimization/98563] [10/11 Regression] vectorization fails while it worked on gcc 9 and earlier since since r10-2271-gd81ab49d0586fca0

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #8)
> (In reply to Jakub Jelinek from comment #7)
> > I'm afraid no.
> > The vectorization can handle addresses into the simd arrays, but right now
> > only if it accesses the whole element, i.e. when we can turn the simd array
> > into a vector register (or set thereof) that hold the variable.
> > In this case that is not the case, as in the end it uses the real and imag
> > parts separately.
> > So, either it can be handled in SRA, or we'd need to teach the vectorizer to
> > permute those fur us.
> 
> Hmm, I see.  The vectorizer can in theory handle "existing" vectors
> (currently only enabled for basic-block SLP though).  But of course the
> first hurdle is
> to not treat those as memory accesses (thus ignore the data-ref analysis
> failure or somehow make that treat the SIMD_LANE indexing "nicely").
> 
> When we see
> 
>   _13 = .GOMP_SIMD_LANE (simduid.0_12(D), 0);
> 
> can we compute how _13 evolves with loop iteration?  Thus, can we
> SCEV analyze it?  Isn't it sth like { .GOMP_SIMD_LANE_START
> (simduid.0_12(D), .GOMP_SIMD_LANE_STEP (simduid.0_12(D), 0) } thus an affine
> evolution
> in the end?

_13 has modulo semantics in the loop, it gets values 0, 1, ... vf-1, 0, 1, ...
vf-1 etc., where vf is the vectorization factor of the loop.
The intent is that after successful vectorization, the array can be promoted to
a vector containing those (or a set of vectors, it is a software vector rather
than necessarily hardware vector) and on unsuccessful vectorization it will
shrink into a single array variable (scalar).

> Simplified C testcase:
> 
> typedef _Complex double cplx;
> void foo (cplx *);
> void test(cplx* __restrict__ a, const cplx* b, double c, int N)
> {
>   cplx tem;
> #pragma omp simd private (tem)
>   for (int i=0; i<8*N; i++) {
>       __real tem = __real b[i];
>       __imag tem = __imag b[i];
>       __real a[i] = __real tem;
>       __imag a[i] = __imag tem;
>   }
>   foo (&tem);

private clause means undefined at the end of construct, if you want to inspect
the value afterwards, the possible clauses are lastprivate (the scalar variable
receives the value from the last iteration), or reduction (in that case it will
reduce it using some base language reduction operator or user defined function
from all the vector elements).

[Bug tree-optimization/98563] [10/11 Regression] vectorization fails while it worked on gcc 9 and earlier since since r10-2271-gd81ab49d0586fca0

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.3                        |10.4

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10.3 is being released, retargeting bugs to GCC 10.4.

[Bug tree-optimization/98563] [10/11/12/13 Regression] vectorization fails while it worked on gcc 9 and earlier since since r10-2271-gd81ab49d0586fca0

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.4                        |10.5

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug tree-optimization/98563] [11/12/13/14 Regression] vectorization fails while it worked on gcc 9 and earlier since since r10-2271-gd81ab49d0586fca0

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.5                        |11.5

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10 branch is being closed.

[Bug tree-optimization/98563] [11/12/13/14 Regression] vectorization fails while it worked on gcc 9 and earlier since since r10-2271-gd81ab49d0586fca0

[pinskia at gcc dot gnu.org]

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

--- Comment #13 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Looking at this, I see in PRE:
  REALPART_EXPR <D.72413[_8]._M_value> = _25;
  IMAGPART_EXPR <D.72413[_8]._M_value> = _26;
  _19 = REALPART_EXPR <MEM <struct complex[16]> [(const struct complex
&)&D.72413][_8]._M_value>;

Should _19 be the same as _25 ?

I suspect if this is done, then the vectorizer would kick in and do the right
thing.