[Bug tree-optimization/56624] New: Vectorizer gives up on a group-access if it contains stores to the same location

[Bug tree-optimization/56624] New: Vectorizer gives up on a group-access if it contains stores to the same location

[michael.v.zolotukhin at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56624

             Bug #: 56624
           Summary: Vectorizer gives up on a group-access if it contains
                    stores to the same location
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: michael.v.zolotukhin@gmail.com
             Build: 4.8.0 20130313


Created attachment 29672
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29672
Reproducer

GCC can't vectorize such loop:
void foo (double *a)
{
  int i;
  for (i = 0; i < 100; i+=2)
    {
      a[i+1] = 2;
      a[i] = 3;
      a[i+1] = 2;
      a[i] = 3;
    }
}
Vectorizer reports following:

note: === vect_analyze_data_ref_accesses === 
note: Detected interleaving of size 2 
note: Two store stmts share the same dr. 
note: not vectorized: complicated access pattern.

Obviously, in this given case vectorization is possible because the first
stores have no effect.

This test is a reproducer of similar problem encountered on Spec2006/470.lbm -
there if-conversion could produce stores to the same location which will stop
vectorizer.

The test is attached, command line to reproduce:
gcc group_access.c -O3 -c -ftree-vectorizer-verbose=15

[Bug tree-optimization/56624] Vectorizer gives up on a group-access if it contains stores to the same location

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56624

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2013-03-15
     Ever Confirmed|0                           |1
      Known to fail|                            |4.8.0
              Build|4.8.0 20130313              |

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> 2013-03-15 11:54:50 UTC ---
> This test is a reproducer of similar problem encountered on Spec2006/470.lbm -
> there if-conversion could produce stores to the same location which will stop
> vectorizer.

Can you reproduce a testcase for that instead?  It doesn't make sense
to handle code that should be optimized earlier (by DSE).  Is it from
code like

 if (cond)
   a[i] = 3;
 else
   a[i] = 3;

?

[Bug tree-optimization/56624] Vectorizer gives up on a group-access if it contains stores to the same location

[michael.v.zolotukhin at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56624

--- Comment #2 from Michael Zolotukhin <michael.v.zolotukhin at gmail dot com> 2013-03-15 12:19:50 UTC ---
> Can you reproduce a testcase for that instead?  It doesn't make sense
> to handle code that should be optimized earlier (by DSE).  Is it from
> code like
> 
>  if (cond)
>    a[i] = 3;
>  else
>    a[i] = 3;
> 
> ?

Yes, originally it is from the code similar to your example, but this example
has one more problem which hides the one described in this tracker. I've
submitted one more bug with the test almost like yours (56625).

[Bug tree-optimization/56624] Vectorizer gives up on a group-access if it contains stores to the same location

[michael.v.zolotukhin at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56624

--- Comment #3 from Michael Zolotukhin <michael.v.zolotukhin at gmail dot com> 2013-03-15 12:26:46 UTC ---
Created attachment 29674
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29674
Reproducer 2

[Bug tree-optimization/56624] Vectorizer gives up on a group-access if it contains stores to the same location

[michael.v.zolotukhin at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56624

--- Comment #4 from Michael Zolotukhin <michael.v.zolotukhin at gmail dot com> 2013-03-15 12:27:51 UTC ---
Sorry, it looks like the reproducer with if could be made, and here it is:
void foo (long *a)
{
  int i;
  for (i = 0; i < 100; i+=2)
    {
      if (a[i] == 0)
        {
          a[i+1] = 2;
          a[i] = 3;
        }
      else
        {
          a[i+1] = 3;
          a[i] = 4;
        }
    }
}
In this example we have:
group_access2.c:4: note: === vect_analyze_data_ref_accesses ===
group_access2.c:4: note: READ_WRITE dependence in interleaving.
group_access2.c:4: note: not vectorized: complicated access pattern.
group_access2.c:4: note: bad data access.
group_access2.c:1: note: vectorized 0 loops in function.

The diagnostic is a bit different, but rootcause is the same I guess.

The test is attached (reproducer 2).

[Bug tree-optimization/56624] Vectorizer gives up on a group-access if it contains stores to the same location

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56624

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
             Blocks|                            |53947

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> 2013-03-15 12:31:57 UTC ---
Thanks and confirmed.

[Bug tree-optimization/56624] Vectorizer gives up on a group-access if it contains stores to the same location

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Michael Zolotukhin from comment #4)
> Sorry, it looks like the reproducer with if could be made, and here it is:
> void foo (long *a)
> {
>   int i;
>   for (i = 0; i < 100; i+=2)
>     {
>       if (a[i] == 0)
>         {
>           a[i+1] = 2;
>           a[i] = 3;
>         }
>       else
>         {
>           a[i+1] = 3;
>           a[i] = 4;
>         }
>     }
> }
> In this example we have:
> group_access2.c:4: note: === vect_analyze_data_ref_accesses ===
> group_access2.c:4: note: READ_WRITE dependence in interleaving.
> group_access2.c:4: note: not vectorized: complicated access pattern.
> group_access2.c:4: note: bad data access.
> group_access2.c:1: note: vectorized 0 loops in function.
> 
> The diagnostic is a bit different, but rootcause is the same I guess.
> 
> The test is attached (reproducer 2).

We now vectorize this loop (not with plain SSE2 but with SSE4.2 for example):

.L2:
        movq    (%rdi), %xmm0
        movdqa  %xmm2, %xmm4
        addq    $16, %rdi
        punpcklqdq      %xmm0, %xmm0
        pcmpeqq %xmm1, %xmm0
        pblendvb        %xmm0, %xmm3, %xmm4
        movups  %xmm4, -16(%rdi)
        cmpq    %rdi, %rax
        jne     .L2

probably because we now sink the common stores from the if arm.  Modifying
the testcase to the following reproduces the original issue again:

void foo (long *a)
{
  int i;
  for (i = 0; i < 100; i+=2)
    {
      if (a[i] == 0)
        {
          a[i+1] = 2;
          a[i] = 3;
        }
      else
        {
          a[i] = 4;
          a[i+1] = 3;
        }
    }
}

[Bug tree-optimization/56624] Vectorizer gives up on a group-access if it contains stores to the same location

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |9.1.0

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Looks like all of the testcases vectorize since GCC 11 as far as I can tell.

[Bug tree-optimization/56624] Vectorizer gives up on a group-access if it contains stores to the same location

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
For aarch64, it has been since GCC 13 though for the testcase in comment #6 .