[Bug middle-end/96281] TBAA does not work as expected for a simple test case

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|other                       |middle-end
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |missed-optimization
                 CC|                            |rguenth at gcc dot gnu.org
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-07-22

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Memory reference 1: s_13(D)->threadid
Memory reference 2: history_h[_3][i_24][j_25]
Querying dependency of refs 1 and 2: dependent.
Querying RAW dependencies of ref 1 in loop 2: dependent
Querying RAW dependencies of ref 1 in loop 1: dependent

so in the inner loop we see

  <bb 9> [local count: 1040670577]:

  <bb 3> [local count: 1057206201]:
  # j_25 = PHI <0(5), j_16(9)>
  _3 = s_13(D)->threadid;
  _4 = history_h[_3][i_24][j_25];
  _5 = _4 + 1;
  _6 = _5 >> 1;
  history_h[_3][i_24][j_25] = _6;
  j_16 = j_25 + 1;
  if (j_16 != 64)
    goto <bb 9>; [98.44%]
  else
    goto <bb 4>; [1.56%]

and while on the entry edge we can CSE s_13(D)->threadid (later PRE does this)
we cannot prove that history_h[_3][i_24][j_25] = _6 does not alters its value.

This looks like a missed optimization as the very same reference is
read before the write.  We might also be able to use path-based
disambiguation here.  That said, 's_13(D)->threadid' should have the
base_alias_set of struct state but then the comment suggests we
know nothing about the dynamic type.

Needs more thoughts and analysis.