Is this use of rtx_addr_varies_p an aliasing bug?

Is this use of rtx_addr_varies_p an aliasing bug?

[Nigel Stephens]

I've been reviewing some patches which I'd made to gcc-2.95, for 
possible merging into 3.4 and 3.5, and I've come across a bug fix which 
still appears to apply - in fact more so in 3.x, since this idiom is now 
used more frequently.

What I see is several calls to true_dependence and canon_true_dependence 
passing a pointer to function rtx_addr_varies_p as their VARIES 
argument, for example in gcse.c:

  if (true_dependence (dest, GET_MODE (dest), gcse_mem_operand,
               rtx_addr_varies_p))
    gcse_mems_conflict_p = 1;

Walking through true_dependence, and then 
fixed_scalar_and_varying_struct_p, the expression which ultimately gets 
passed to the VARIES function is not the original MEM, but the address 
of the MEM, e.g.

  if (MEM_SCALAR_P (mem1) && MEM_IN_STRUCT_P (mem2)
      && !varies_p (mem1_addr, 1) && varies_p (mem2_addr, 1))
    /* MEM1 is a scalar at a fixed address; MEM2 is a struct at a
       varying address.  */
    return mem1;

But then looking at rtx_addr_varies_p, the only thing which can make it 
return true is if it finds a MEM whose address varies (rtx_varies_p). 
This seems to be wrong because it will never (except on some CISC 
architectures I guess) be passed the enclosing MEM. My hunch is that all 
current uses of rtx_addr_varies_p should be replaced by rtx_varies_p, 
and rtx_addr_varies_p should then be removed. Does that make sense, or 
have I missed something?

Regards

Nigel

Re: Is this use of rtx_addr_varies_p an aliasing bug?

[Jim Wilson]

Nigel Stephens wrote:
> architectures I guess) be passed the enclosing MEM. My hunch is that all 
> current uses of rtx_addr_varies_p should be replaced by rtx_varies_p, 
> and rtx_addr_varies_p should then be removed. Does that make sense, or 
> have I missed something?

gcc-bugs is not a very good place for questions like this.  gcc-bugs is 
primarily used for output from the bugzilla bug database.  You are 
better off sending questions like this to the gcc list.

Yes, this all makes sense.  This looks like it has been broken ever 
since the  fixed_scalar_and_varying_struct_p function was first created, 
which was in between the 2.8 and 2.95 releases.

rtx_addr_varies_p does do one more thing than rtx_varies_p.  It returns 
true if passed a BLKmode MEM.  I wonder if this explains why we have 
been having all sorts of BLKmode related problems with MEM_IN_STRUCT_P 
in the gcc-3.4 release process.  Perhaps some of them would go away if 
we re-added the BLKmode test.

At this point though, we have been clearly operating without the BLKmode 
test for over 5 years, so there is no overriding need to keep it.

I think it looks right to replace all current uses of rtx_addr_varies_p 
with rtx_varies_p.  This might expose optimizer issues though, since it 
will make the MEM_IN_STRUCT_P optimizations work in cases where they 
have been accidentally disabled for 5 years, so we will have to be 
careful about that.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com