[Bug tree-optimization/49695] New: conditional moves for stores

[Bug tree-optimization/49695] New: conditional moves for stores

[revital.eres at linaro dot org]

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

           Summary: conditional moves for stores
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: revital.eres@linaro.org


for (i = 0; i < point1->len; i++)
    {
      if (point1->arr[i].val)
        {
          point1->arr[i].val ^= (unsigned long long) res;
        }
    }

For the above loop if-conversion is not been done in the tree level (compiled
with trunk -r176116). Seemingly this case is similar to the one in PR27313.
When using -ftree-loop-if-convert-stores I get 'tree could trap...' message
although I'm not sure why as there is a read in every iteration of the loop to
the memory location we write to.
Similar case appears in SPEC2006/libquantum.

Here's a snippet from .ifcvt file:

<bb 3>:
  pretmp.6_33 = point1_3(D)->arr;

<bb 4>:
  # i_27 = PHI <i_22(7), 0(3)>
  i.0_6 = (unsigned int) i_27;
  D.3689_7 = i.0_6 * 8;
  D.3690_8 = pretmp.6_33 + D.3689_7;
  D.3691_9 = D.3690_8->val;
  if (D.3691_9 != 0)
    goto <bb 5>;
  else
    goto <bb 6>;

<bb 5>:
  D.3694_20 = (long long unsigned int) res_19(D);
  D.3695_21 = D.3694_20 ^ D.3691_9;
  D.3690_8->val = D.3695_21;

<bb 6>:
  i_22 = i_27 + 1;
  if (i_22 < D.3696_29)
    goto <bb 7>;
  else
    goto <bb 8>;

<bb 7>:
  goto <bb 4>;

[Bug tree-optimization/49695] conditional moves for stores

[revital.eres at linaro dot org]

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

--- Comment #1 from revital.eres at linaro dot org 2011-07-10 10:05:07 UTC ---
Created attachment 24730
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24730
Testcase which contains the loop

[Bug tree-optimization/49695] conditional moves for stores

[revital.eres at linaro dot org]

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

--- Comment #2 from revital.eres at linaro dot org 2011-07-10 12:50:31 UTC ---
(In reply to comment #0)
> for (i = 0; i < point1->len; i++)
>     {
>       if (point1->arr[i].val)
>         {
>           point1->arr[i].val ^= (unsigned long long) res;
>         }
>     }
> For the above loop if-conversion is not been done in the tree level (compiled
> with trunk -r176116). Seemingly this case is similar to the one in PR27313.
> When using -ftree-loop-if-convert-stores I get 'tree could trap...' message
> although I'm not sure why as there is a read in every iteration of the loop to
> the memory location we write to.

hmmm... after reading Sebastian Pop's paper from the last summit ("Improving
GCC’s auto-vectorization with if-conversion and loop
flattening for AMD’s Bulldozer processors") it's seems that we need to grantee
that point1->arr[i].val is writable when the condition is false which we can
not prove in this case.  So that's not a bug, I apologize for the noise.

[Bug tree-optimization/49695] conditional moves for stores

[revital.eres at linaro dot org]

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

--- Comment #3 from revital.eres at linaro dot org 2011-07-10 13:41:07 UTC ---
> > the memory location we write to.
> hmmm... after reading Sebastian Pop's paper from the last summit ("Improving
> GCC’s auto-vectorization with if-conversion and loop
> flattening for AMD’s Bulldozer processors") it's seems that we need to grantee
> that point1->arr[i].val is writable when the condition is false which we can
> not prove in this case.  So that's not a bug, I apologize for the noise.

Continuing reading the paper I see that under the 'If-conversion without
restrictions' section there is a technique that allows to apply if-conversion
in the above case by writing to artificial object that has been
created by the compiler when the condition is false. I assume this method is
not implemented in trunk yet.

[Bug tree-optimization/49695] conditional moves for stores

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|UNCONFIRMED                 |RESOLVED
   Target Milestone|---                         |12.0
      Known to work|                            |12.1.0

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
On x86_64 with AVX2, and masked stores, GCC 12 is able to vectorize this loop
just fine.

On aarch64 with SVE2, GCC 12 is also able to vectorize the loop just fine too.

I am just going to close as fixed.