summaryrefslogtreecommitdiffstats
path: root/llvm/utils/TableGen/CodeEmitterGen.cpp
diff options
context:
space:
mode:
authorMax Kazantsev <max.kazantsev@azul.com>2017-10-11 07:26:45 +0000
committerMax Kazantsev <max.kazantsev@azul.com>2017-10-11 07:26:45 +0000
commit0c8dd052b828ca2f0bcbad5398cef010d60649d4 (patch)
tree3334cde8d547242769601770a1c54d504ff31e95 /llvm/utils/TableGen/CodeEmitterGen.cpp
parent25d8655dc22cae27c2c5190577370e558c5afff5 (diff)
downloadbcm5719-llvm-0c8dd052b828ca2f0bcbad5398cef010d60649d4.tar.gz
bcm5719-llvm-0c8dd052b828ca2f0bcbad5398cef010d60649d4.zip
[LICM] Disallow sinking of unordered atomic loads into loops
Sinking of unordered atomic load into loop must be disallowed because it turns a single load into multiple loads. The relevant section of the documentation is: http://llvm.org/docs/Atomics.html#unordered, specifically the Notes for Optimizers section. Here is the full text of this section: > Notes for optimizers > In terms of the optimizer, this **prohibits any transformation that > transforms a single load into multiple loads**, transforms a store into > multiple stores, narrows a store, or stores a value which would not be > stored otherwise. Some examples of unsafe optimizations are narrowing > an assignment into a bitfield, rematerializing a load, and turning loads > and stores into a memcpy call. Reordering unordered operations is safe, > though, and optimizers should take advantage of that because unordered > operations are common in languages that need them. Patch by Daniil Suchkov! Reviewed By: reames Differential Revision: https://reviews.llvm.org/D38392 llvm-svn: 315438
Diffstat (limited to 'llvm/utils/TableGen/CodeEmitterGen.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud