This is the mail archive of the gcc-patches@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: [PATCH, alpha]: Wrap {un,}aligned_store sequence with memory blockages.


On Mon, Jul 7, 2014 at 4:34 PM, Richard Biener
<richard.guenther@gmail.com> wrote:
> On Mon, Jul 7, 2014 at 4:20 PM, Richard Henderson <rth@redhat.com> wrote:
>> On 07/07/2014 02:10 AM, Richard Biener wrote:
>>> On Mon, Jun 30, 2014 at 5:54 PM, Richard Henderson <rth@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~
>>


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