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/Transforms/Utils/LoopUtils.cpp | |
| parent | abcdc5e3a898766cf16984386bd9f7c98f2cbbe0 (diff) | |
| download | llvm-dfd890dd3a0fe92e5eea08b99e0cc9776690392f.zip llvm-dfd890dd3a0fe92e5eea08b99e0cc9776690392f.tar.gz llvm-dfd890dd3a0fe92e5eea08b99e0cc9776690392f.tar.bz2 | |
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/Transforms/Utils/LoopUtils.cpp')
0 files changed, 0 insertions, 0 deletions