Re: RTL infrastructure leaks VALUE expressions into aliasing-detecting functions

[Jeff Law <law at redhat dot com>]

On 10/10/14 12:12, Uros Bizjak wrote:
> On Fri, Oct 10, 2014 at 7:56 PM, Jeff Law <law@redhat.com> wrote:
> > On 10/09/14 06:14, Uros Bizjak wrote:
> > > Hello!
> > >
> > > I'd like to bring PR 63475 to the attention of RTL maintainers. The
> > > problem in the referred PR exposed the RTL infrastructure problem,
> > > where VALUE expressions are leaked instead of MEM expresions into
> > > various parts of aliasing-detecting support functions.
> > >
> > > As an example, please consider following patch for base_alias_check:
> > >
> > > --cut here--
> > > Index: alias.c
> > > ===================================================================
> > > --- alias.c     (revision 216025)
> > > +++ alias.c     (working copy)
> > > @@ -1824,6 +1824,13 @@ base_alias_check (rtx x, rtx x_base, rtx y, rtx y_
> > >      if (rtx_equal_p (x_base, y_base))
> > >        return 1;
> > >
> > > +  if (GET_CODE (x) == VALUE || GET_CODE (y) == VALUE)
> > > +    {
> > > +      debug_rtx (x);
> > > +      debug_rtx (y);
> > > +      gcc_unreachable ();
> > > +    }
> > > +
> > >      /* The base addresses are different expressions.  If they are not
> > > accessed
> > >         via AND, there is no conflict.  We can bring knowledge of object
> > >         alignment into play here.  For example, on alpha, "char a, b;" can
> >
> > But when base_alias_check  returns, we call memrefs_conflict_p which does
> > know how to dig down into a VALUE expression.
>
> IIRC, the problem was that base_alias_check returned 0 due to:
>
>    /* Differing symbols not accessed via AND never alias.  */
>    if (GET_CODE (x_base) != ADDRESS && GET_CODE (y_base) != ADDRESS)
>      return 0;
>
> so, the calling code never reached memrefs_conflict_p down the stream.
Right.  And my question is what happens if we aren't as aggressive here. 
  What happens if before this check we return nonzero if X or Y is a 
VALUE?  Do we then get into memrefs_conflict_p and does it do the right 
thing?



> It might be that targets without AND addresses are immune to this
> issue, but the code that deals with ANDs is certailny not prepared to
> handle VALUEs.
>
> (The testcase from the PR can be compiled with a crosscompiler to
> alpha-linux-gnu, as outlined in the PR. Two AND addresses should be
> detected as aliasing, but they are not - resulting in CSE propagating
> aliased read after store in (insn 29).)
Yea, but I'm slammed right now and won't be able to look at it under a 
debugger for a while.

jeff