summaryrefslogtreecommitdiffstats
path: root/llvm/tools/llvm-dwarfdump
diff options
context:
space:
mode:
authorRichard Sandiford <rsandifo@linux.vnet.ibm.com>2013-12-10 10:49:34 +0000
committerRichard Sandiford <rsandifo@linux.vnet.ibm.com>2013-12-10 10:49:34 +0000
commitbef3d7af2b8d0153a6935faa776ed1495d3e5e5e (patch)
tree3f62a923ee7d2c523386c80ed8756805a71fd9a9 /llvm/tools/llvm-dwarfdump
parent9afe613d121c99e66ca2224dcb426604867151e3 (diff)
downloadbcm5719-llvm-bef3d7af2b8d0153a6935faa776ed1495d3e5e5e.tar.gz
bcm5719-llvm-bef3d7af2b8d0153a6935faa776ed1495d3e5e5e.zip
Add TargetLowering::prepareVolatileOrAtomicLoad
One unusual feature of the z architecture is that the result of a previous load can be reused indefinitely for subsequent loads, even if a cache-coherent store to that location is performed by another CPU. A special serializing instruction must be used if you want to force a load to be reattempted. Since volatile loads are not supposed to be omitted in this way, we should insert a serializing instruction before each such load. The same goes for atomic loads. The patch implements this at the IR->DAG boundary, in a similar way to atomic fences. It is a no-op for targets other than SystemZ. llvm-svn: 196906
Diffstat (limited to 'llvm/tools/llvm-dwarfdump')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud