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 07/07/2014 07:34 AM, Richard Biener wrote:
> Ugh.  I wasn't aware of that - is this documented anywhere?  What
> exactly does such address conflict with?  Does it inhibit type-based analysis?

Dunno if it's documented anywhere.  Such addresses conflict with anything,
unless it can be proven not to be overlapping with the alignment.

> Where do those ANDs come from?

Usually the move expander for the mode.

> 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).

It's not the loads, per se, it's the stores that get in the way.

Early alpha can't store sub-4-byte quantities.  Altivec can't store anything
but 16 byte quantities.  In order to perform smaller stores, we have to do a
read-modify-write sequence on a larger aligned chunk of memory.  Two such RMW
sequences must conflict, lest we interleave and thus bork the operation.

I don't recall how much we ever did for this, exactly, but it's certainly
possible to know that some memory operations cannot conflict with these RMW
sequence.  E.g. through size + alignment of the other memory operation.  E.g.
on Alpha, a byte RMW store can't conflict with a normal DImode memory access.

> Btw, if the mem is MEM_READONLY_P how can it be part of
> a {un}aligned_store sequence?

Er... that's an excellent question.  Uros?


r~


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