https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
--- Comment #15 from Uroš Bizjak <ubizjak at gmail dot com> --- (In reply to rguent...@suse.de from comment #14) > I see. But you don't touch write_dependence which has a similar check. I have in fact changed all these places (I will attach the patch momentarily), but the attached test check one location only. After the approach is considered OK, the others are trivial to add. > And instead of making the check for AND disable the MEM_READONLY_P > early-out wouldn't it be more correct to treat MEMs with AND addresses > as true barriers? That is, > > if (GET_CODE (x_addr) == AND > || GET_CODE (mem_addr) == AND) > return 1; > > if (MEM_READONLY_P (x)) > return 0; > > instead? I see we're trying to be clever with AND addresses even > though they are "barriers", why's that? This was my first approach. But DImode (8-byte) reads, aligned to their natural alignment, can't alias locations that are re-aligned to 8-bytes using alignment ANDs. This is what the code downstream handles, so the approach, proposed above would penalize DImode reads too much. > Note that all this should only ever be an issue with that very old Alpha > as other archs should implement the C++ memory model properly. Unfortunately, I have to agree. The alternative would be a target-specific change that would mark all memory in RMW sequence with some kind of barrier. IMO, the generic change is preferable, since it doesn't affect other targets, and makes aliasing more robust w.r.t. to target peculiarities.
