[PATCH] Use target-dependent emitLeading/TrailingFence instead of the target-independent insertLeading/TrailingFence (in AtomicExpandPass)

Robin Morisset morisset at google.com
Mon Aug 18 15:10:36 PDT 2014


Hi jfb,

Fixes two latent bugs:
- There was no fence inserted before expanded seq_cst load (unsound on Power)
- There was only a fence release before seq_cst stores (again unsound, in particular on Power)
    It is not even clear if this is correct on ARM swift processors (where release fences are
    DMB ishst instead of DMB ish)
These two bugs were not triggered because Power is not (yet) using this pass, and these
behaviours happen to be (mostly?) working on ARM
(although they completely butchered the semantics of the llvm IR).
See:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075821.html
for an example of the problems that can be caused by the second of these bugs.

I couldn't see a way of fixing these in a completely target-independent way without
adding lots of unnecessary fences on ARM, hence the target-dependent parts of this
patch.
Depends on D4958, D4959, D4960.

http://reviews.llvm.org/D4961

Files:
  lib/CodeGen/AtomicExpandPass.cpp
  test/CodeGen/ARM/cmpxchg-idioms.ll
  test/Transforms/AtomicExpand/ARM/atomic-expansion-v7.ll
  test/Transforms/AtomicExpand/ARM/cmpxchg-weak.ll
  test/Transforms/AtomicExpand/ARM/lit.local.cfg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: D4961.12631.patch
Type: text/x-patch
Size: 18513 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140818/76916f9c/attachment.bin>


More information about the llvm-commits mailing list