https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697
--- Comment #51 from mwahab at gcc dot gnu.org --- (In reply to Andrew Macleod from comment #50) > Created attachment 35478 [details] > implement SYNC flag for memory model > > > Adding the __sync barriers to coretypes.h is the better approach if more > > than one backend has this problem. Since it seems that only Aarch64 is > > affected, I think its better to go with the target hook. If a new > > architecture gets added with the same problem, it will be easy enough to > > switch to the coretypes.h approach. > > Well, if it affects some target now, it likely to affect some target in the > future as well. Didn't someone also mention there is a potential issue with > PPC somewhere too? The earlier comment (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65697#c24) suggests that PPC generates full barriers so won't be affected by this. It looks like Aarch64 is the only current target with the problem. > In any case, I'm not a fan of adding target hooks for this... We ought to > just bite the bullet and integrate it cleanly into the memory model. OK. > I have a patch which adds a SYNC flag to the upper bit of the memory model. > It modifies all the generic code and target patterns to use access routines > (declared in tree.h) instead of hard coding masks and flags (which probably > should have be done in the first place). This makes carrying around the SYNC > flag transparent until you want to look for it. >From a quick look, this seems to do what's needed to allow the Aarch64 backend to distinguish the sync and atomic code. > This compiles on all targets, but is only runtime tested on > x86_64-unknown-linux-gnu with no regressions. The mips backend was the only one that stood out as needing some care, because the way it uses the memory models (e.g. in function mips_process_sync_loop) is a little different from the backends. > With this you should be able to easily issue whatever different insn > sequence you need to within an atomic pattern. Give it a try. If it works > as required, then we'll see about executing on all targets for testing... I'll give it a go.
