diff options
author | Philip Reames <listmail@philipreames.com> | 2015-08-27 01:32:33 +0000 |
---|---|---|
committer | Philip Reames <listmail@philipreames.com> | 2015-08-27 01:32:33 +0000 |
commit | dfd890dd3a0fe92e5eea08b99e0cc9776690392f (patch) | |
tree | f5ba71199fabdef94c27279c9fec988df3926dd9 /llvm/lib | |
parent | abcdc5e3a898766cf16984386bd9f7c98f2cbbe0 (diff) | |
download | bcm5719-llvm-dfd890dd3a0fe92e5eea08b99e0cc9776690392f.tar.gz bcm5719-llvm-dfd890dd3a0fe92e5eea08b99e0cc9776690392f.zip |
Allow value forwarding past release fences in EarlyCSE
A release fence acts as a publication barrier for stores within the current thread to become visible to other threads which might observe the release fence. It does not require the current thread to observe stores performed on other threads. As a result, we can allow store-load and load-store forwarding across a release fence.
We do need to make sure that stores before the fence can't be eliminated even if there's another store to the same location after the fence. In theory, we could reorder the second store above the fence and *then* eliminate the former, but we can't do this if the stores are on opposite sides of the fence.
Note: While more aggressive then what's there, this patch is still implementing a really conservative ordering. In particular, I'm not trying to exploit undefined behavior via races, or the fact that the LangRef says only 'atomic' accesses are ordered w.r.t. fences.
Differential Revision: http://reviews.llvm.org/D11434
llvm-svn: 246134
Diffstat (limited to 'llvm/lib')
-rw-r--r-- | llvm/lib/Transforms/Scalar/EarlyCSE.cpp | 11 |
1 files changed, 11 insertions, 0 deletions
diff --git a/llvm/lib/Transforms/Scalar/EarlyCSE.cpp b/llvm/lib/Transforms/Scalar/EarlyCSE.cpp index 029b44c2ea8..01abbb8ad9e 100644 --- a/llvm/lib/Transforms/Scalar/EarlyCSE.cpp +++ b/llvm/lib/Transforms/Scalar/EarlyCSE.cpp @@ -613,6 +613,17 @@ bool EarlyCSE::processNode(DomTreeNode *Node) { continue; } + // A release fence requires that all stores complete before it, but does + // not prevent the reordering of following loads 'before' the fence. As a + // result, we don't need to consider it as writing to memory and don't need + // to advance the generation. We do need to prevent DSE across the fence, + // but that's handled above. + if (FenceInst *FI = dyn_cast<FenceInst>(Inst)) + if (FI->getOrdering() == Release) { + assert(Inst->mayReadFromMemory() && "relied on to prevent DSE above"); + continue; + } + // Okay, this isn't something we can CSE at all. Check to see if it is // something that could modify memory. If so, our available memory values // cannot be used so bump the generation count. |