search for: atomicexpandloadlink

...pproach seems reasonable. I've had a quick glance at the patches, and the code seems fairly sane. But I'm not so sure about starting with a new pass then deleting the other two. I think it's likely to muddy the revision control history. I'd prefer to see a gradual evolution of the AtomicExpandLoadLinked.cpp (perhaps starting with a "git mv" and some internal renaming to stake out the intent, followed by adding and using the extra hooks). Cheers. Tim.

...ady made in the mid-end. My Proposal ----------- I think the best way to solve this longer term is to add explicit "load linked" and "store conditional" instructions to the LLVM IR, with equal status to "cmpxchg" and "atomicrmw". We could then simplify the AtomicExpandLoadLinked pass to use these, change it to use something like a TargetTransformInfo hook instead of TargetLowering and schedule it much earlier in the mid-end. X86 & SystemZ would simply request no expansion happen. This means Clang could still emit cmpxchg and atomicrmw, which closely match C & C+...

> From my reading of Atomics.rst, it would be sound to reorder (It does not > say much about load-linked, so I am treating it as a normal load here) > >> store seq_cst >> fence release >> load-linked monotonic > > into > >> load-linked monotonic >> store seq_cst >> fence release > Which would make an execution ending in %old_x = %old_y = 0