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?
Richard.
>> Maybe use ALIAS_SET_MEMORY_BARRIER instead?
>
> r~
>
