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

2024-03-09 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56624

--- Comment #8 from Andrew Pinski  ---
For aarch64, it has been since GCC 13 though for the testcase in comment #6 .

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

2024-03-09 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56624

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||9.1.0

--- Comment #7 from Andrew Pinski  ---
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

2020-09-14 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56624

--- Comment #6 from Richard Biener  ---
(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

2013-03-15 Thread 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

2013-03-15 Thread 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

2013-03-15 Thread 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

2013-03-15 Thread 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

2013-03-15 Thread 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.