On Mon, Jul 7, 2014 at 4:34 PM, Richard Biener
<richard.guent...@gmail.com> wrote:
> On Mon, Jul 7, 2014 at 4:20 PM, Richard Henderson <r...@redhat.com> wrote:
>> On 07/07/2014 02:10 AM, Richard Biener wrote:
>>> On Mon, Jun 30, 2014 at 5:54 PM, Richard Henderson <r...@redhat.com> wrote:
>>>> On 06/29/2014 11:14 AM, Uros Bizjak wrote:
>>>>> if (MEM_READONLY_P (x))
>>>>> + if (GET_CODE (mem_addr) == AND)
>>>>> + return 1;
>>>>> return 0;
>>>>
>>>> Certainly missing braces here. But with that fixed the patch looks
>>>> plausible.
>>>> I'll look at it closer later today.
>>>
>>> Umm... but certainly a very gross hack for a special target in a very
>>> general routine.
>>>
>>> So - please no!
>>>
>>> If addresses with AND are supposed to be barriers then you should
>>> model this explicitely in the IL and not make it work "magically".
>>
>> Huh? We've supported AND as a conflict-with-most address for like forever.
>> It's not just Alpha that uses them either; at least Altivec as well.
>
> Ugh. I wasn't aware of that - is this documented anywhere? What
> exactly does such address conflict with? Does it inhibit type-based analysis?
>
> Where do those ANDs come from? If there were a target where
> ANDs would be valid part of addresses in memory accesses but
> they wouldn't impose such barriers how'd we deal with that
> (altivec aligned (masked) loads come to my mind - I don't see why
> they would conflict with more than they say).
>
> Btw, if the mem is MEM_READONLY_P how can it be part of
> a {un}aligned_store sequence?
Looking at the testcase I see how we might mishandle RMW
ops here (but still fail to see why MEM_READONLY_P should
be an issue). There is an old bug where this sort of thing
triggers on x86_64 as well from generic expansion of block
copies IIRC where we store with a word_mode sequence but
fail to use a smaller mode for the last piece (PR36043 if I
remember correctly).
As for the alias issue it would be nice if the RTL alias oracle
would be able to early out if memrefs_conflict_p would detect
a must-alias.
Richard.
> Richard.
>
>>> Maybe use ALIAS_SET_MEMORY_BARRIER instead?
>>
>> r~
>>
