RTL infrastructure leaks VALUE expressions into aliasing-detecting functions

[Jeff Law]

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