This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Fri, Oct 10, 2014 at 8:18 PM, Jeff Law <law@redhat.com> wrote:

>>>> 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?

Following patch just after AND detection in base_alias_check fixes the
testcase from PR:

--cut here--
Index: alias.c
===================================================================
--- alias.c     (revision 216100)
+++ alias.c     (working copy)
@@ -1842,6 +1842,8 @@ base_alias_check (rtx x, rtx x_base, rtx y, rtx y_
          || (int) GET_MODE_UNIT_SIZE (x_mode) < -INTVAL (XEXP (y, 1))))
     return 1;

+  return 1;
+
   /* Differing symbols not accessed via AND never alias.  */
   if (GET_CODE (x_base) != ADDRESS && GET_CODE (y_base) != ADDRESS)
     return 0;
--cut here--

I have started a bootstrap on alpha native with this patch (it will
take a day or so) and will report back findings

The results with unpatched gcc are at [1].

[1] https://gcc.gnu.org/ml/gcc-testresults/2014-10/msg01151.html

Uros.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]