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.
