On Fri, Oct 10, 2014 at 7:56 PM, Jeff Law <l...@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.
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).)
Uros.
