[Bug target/65697] __atomic memory barriers not strong enough for __sync builtins

["mwahab at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697

--- Comment #29 from mwahab at gcc dot gnu.org ---
(In reply to mwahab from comment #27)
> (In reply to Andrew Macleod from comment #25)
> > My opinion:
> > 
> > 1) is undesirable... even though it could possibly accelerate the conversion
> > of legacy sync to atomic calls... I fear it would instead just cause
> > frustration, annoyance and worse.  I don't think we need to actually
> > penalize sync for no reason better than a 1 in a somethillion shot in the
> > dark.
> > 
> > 2) Similar reasoning, I don't think we need to penalize SEQ_CST everywhere
> > for a legacy sync call that probably doesn't need stronger code either.
> > 
> > which leaves option 3)
> > 
> > There are 2 primary options I think


There may be a third option, which is to set-up a target hook to allow the sync
expansions in the middle end to be overridden. This limits the changes to the
backends that need the different semantics without having to continue with the
sync_ patterns (which aren't in aarch64 for example). There's space in the
memmodel values to support target specific barriers so, for aarch64, this would
allow the atomics code to be reused. I don't know much about the target hook
infrastructure though so I don't know how disruptive a new hook would be.