[Bug tree-optimization/110702] [12/13/14 Regression] Wrong code at -O1 on x86_64-linux-gnu (regression since GCC-12.2)

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|needs-bisection             |
             Status|NEW                         |ASSIGNED
                 CC|                            |hubicka at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot 
gnu.org
          Component|middle-end                  |tree-optimization

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think the bisected rev just exposes an existing issue.  Namely IVOPTs
generates

  _1 = MEM[(long int *)_52];
  _3 = MEM[(long int *)0B + ivtmp.36_9 + ivtmp.28_44 * 4];
  _4 = (int) _3;
  _2 = (int) _1;
  _5 = _2 | _4;

with -fno-ivopts it works fine and we sink

  _1 = e[0][0][b.7_29];
  _3 = e[a.9_30][b.7_29][a.9_30];

the issue is without IVOPTs the late pure-const pass correctly does nothing
but with IVOPTs and the above MEMs we get it to produce pure because:

  scanning: _1 = MEM[(long int *)_52];
    Indirect ref read is not const
  NULL memory access; terminating BB

which is because infer_nonnull_range_by_dereference eventually does

static bool
check_loadstore (gimple *, tree op, tree, void *data)
{
  if (TREE_CODE (op) == MEM_REF || TREE_CODE (op) == TARGET_MEM_REF)
    {                           
      /* Some address spaces may legitimately dereference zero.  */
      addr_space_t as = TYPE_ADDR_SPACE (TREE_TYPE (op));
      if (targetm.addr_space.zero_address_valid (as))
        return false;

      return operand_equal_p (TREE_OPERAND (op, 0), (tree)data, 0);