[Bug tree-optimization/101548] New: dependence analysis fails with .MASK_STORE

[Bug tree-optimization/101548] New: dependence analysis fails with .MASK_STORE

[rguenth at gcc dot gnu.org]

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

            Bug ID: 101548
           Summary: dependence analysis fails with .MASK_STORE
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

We fail to vectorize (with -fno-trapping-math in case COND_ADD is not
available)

double a[1024], b[1024];

void foo ()
{
  for (int i = 0; i < 1024; ++i)
    if (b[i] < 3.)
      a[i] += b[i];
}

the loop is if-converted to

  <bb 3> [local count: 1063004409]:
  # i_13 = PHI <i_9(7), 0(15)>
  # ivtmp_6 = PHI <ivtmp_4(7), 1024(15)>
  _1 = b[i_13];
  _2 = a[i_13];
  _3 = _1 + _2;
  _24 = _1 < 3.0e+0;
  _25 = &a[i_13];
  .MASK_STORE (_25, 64B, _24, _3);
  i_9 = i_13 + 1;
  ivtmp_4 = ivtmp_6 - 1;
  if (ivtmp_4 != 0)
    goto <bb 7>; [98.99%]
  else
    goto <bb 6>; [1.01%]

but then dependence analysis fails:

(compute_affine_dependence
  ref_a: b[i_13], stmt_a: _1 = b[i_13];
  ref_b: *_25, stmt_b: .MASK_STORE (_25, 64B, _24, _3);
) -> no dependence
(compute_affine_dependence
  ref_a: a[i_13], stmt_a: _2 = a[i_13];
  ref_b: *_25, stmt_b: .MASK_STORE (_25, 64B, _24, _3);
) -> dependence analysis failed
t3.c:7:12: missed:   versioning for alias required: can't determine dependence
between a[i_13] and *_25
consider run-time aliasing test between a[i_13] and *_25

and then

t3.c:5:21: note:   === vect_prune_runtime_alias_test_list ===
t3.c:5:21: note:   can tell at compile time that a[i_13] and *_25 alias
t3.c:7:12: missed:   not vectorized: compilation time alias: _2 = a[i_13];
.MASK_STORE (_25, 64B, _24, _3);

and we give up.  But the may-dependence does not prevent vectorization.

[Bug tree-optimization/101548] dependence analysis fails with .MASK_STORE

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
It works with

void foo (double * __restrict a, double *b)
{
  for (int i = 0; i < 1024; ++i)
    {
      double tem = a[i];
      if (b[i] < tem)
        a[i] = tem + b[i];
    }
}

and

  <bb 3> [local count: 1063004409]:
  # i_20 = PHI <i_15(7), 0(15)>
  # ivtmp_19 = PHI <ivtmp_18(7), 1024(15)>
  _1 = (long unsigned int) i_20;
  _2 = _1 * 8;
  _3 = a_11(D) + _2;
  tem_12 = *_3;
  _4 = b_13(D) + _2;
  _5 = *_4;
  _6 = _5 + tem_12;
  _34 = _5 < tem_12;
  .MASK_STORE (_3, 64B, _34, _6);
  i_15 = i_20 + 1;
  ivtmp_18 = ivtmp_19 - 1;
  if (ivtmp_18 != 0)
    goto <bb 7>; [98.99%]
  else
    goto <bb 6>; [1.01%]

so this is likely a duplicate of the old issue of refs based on a pointer
(which .MASK_STORE with &a[i] is) wrt refs based not on a pointer (a[i]).

[Bug tree-optimization/101548] dependence analysis fails with .MASK_STORE

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |crazylht at gmail dot com

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
*** Bug 101752 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/101548] dependence analysis fails with .MASK_STORE

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
quite exact duplicate

*** This bug has been marked as a duplicate of bug 65206 ***