search for: atomicexpandloadlinkedpass

> 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

> Longer term, I hope to improve the fence elimination of the ARM backend with > a kind of PRE algorithm. Both of these improvements to the ARM backend > should be fairly straightforward to port to the POWER architecture later, > and I hope to also do that. > > Any reason these couldn't be done at the IR level? I definitely agree here. At the time, it was a plausible idea

...r example on Power a > seq_cst store has a fence before it, while on ARM it has a fence > both before and after it (per http://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html) That certainly seems to suggest some kind of parametrisation. > For this exact reason, I am planning on splitting AtomicExpandLoadLinkedPass > in a target-independent and a target-dependent file: the current pass claims > to be target-independent but is actually designed for ARM: for example it > puts a release-fence before a seq_cst CAS, which would be unsound on Power > if the backend was more agressive and using lwsync fo...