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~
