[Bug middle-end/90348] [7/8/9/10 Regression] Partition of char arrays is incorrect in some cases

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think before ivopts this looks fine, we have:
  <bb 3> [local count: 858993460]:
  # j_20 = PHI <0(10), j_13(11)>
  in[j_20] = 0;
  set_one (&buf);
  buf ={v} {CLOBBER};
  j_13 = j_20 + 1;
  if (i_6 > j_20)
    goto <bb 11>; [80.00%]
  else
    goto <bb 4>; [20.00%]
in the inner loop and
  <bb 7> [local count: 214748365]:
  in ={v} {CLOBBER};
  i_10 = i_6 + 1;
  ivtmp_22 = ivtmp_4 - 1;
  if (ivtmp_22 != 0)
    goto <bb 8>; [80.00%]
  else
    goto <bb 9>; [20.00%]
near the end of the outer loop.  The problem is that ivopts turns the in[j_20]
access into
  <bb 2> [local count: 42959980]:
  _30 = (unsigned int) &in;
  ivtmp.27_29 = _30 + 1;
  goto <bb 5>; [100.00%]

  <bb 10> [local count: 171798691]:
  ivtmp.21_16 = (unsigned int) &in;
  _23 = (unsigned int) &in;

  <bb 3> [local count: 858993460]:
  # ivtmp.21_21 = PHI <ivtmp.21_16(10), ivtmp.21_3(11)>
  _18 = (void *) ivtmp.21_21;
  MEM[base: _18, offset: 0B] = 0;
  set_one (&buf);
  buf ={v} {CLOBBER};
which is still fine, for the life analysis we still see in as live in bb 10 and
therefore in bb3 too.
But later on dom3 changes
   <bb 3> [local count: 171798691]:
-  ivtmp.21_16 = (unsigned int) &in;
-  _23 = (unsigned int) &in;
+  ivtmp.21_16 = _30;
+  _23 = _30;
and now &in is live clearly only in bb2 before the outer loop for the life
analysis purposes.  Now, if we kill that
      if (gimple_clobber_p (stmt))
        {
          tree lhs = gimple_assign_lhs (stmt);
          size_t *v;
          /* Nested function lowering might introduce LHSs
             that are COMPONENT_REFs.  */
          if (!VAR_P (lhs))
            continue;
          if (DECL_RTL_IF_SET (lhs) == pc_rtx
              && (v = decl_to_stack_part->get (lhs)))
            bitmap_clear_bit (work, *v);
        }
you've mentioned, I'm afraid we lose all the stack slot sharing possibilities,
or at least most of them.
So I'm afraid we need to do something smarter.
Either we need to track during the life analysis algorithm what variables
SSA_NAMEs can point to (even for non-pointers, as in this testcase ivopts uses
an integral value (unsigned int) &in and then later casts to integers), or
could we use the alias analysis points to information for that?

For this testcase, it would be enough to walk for referenced pointer SSA_NAMEs
through their points to variables and mark those variables as also seen in the
IL.