SROA currently ignores loads and stores being atomic. When rewriting instructions, copy the atomic property to the new instructions.
Concerning integer- or vector-promotion, treat atomic like volatile and don't promote.
Paths
| Differential D10276
[SROA] Fix for PR23737: Handle Atomic when rewriting Loads and Stores AbandonedPublic Authored by philip.pfaffe on Jun 5 2015, 5:42 AM.
Details
Summary SROA currently ignores loads and stores being atomic. When rewriting instructions, copy the atomic property to the new instructions. Concerning integer- or vector-promotion, treat atomic like volatile and don't promote.
Diff Detail Event Timelinephilip.pfaffe retitled this revision from to [SROA] Fix for PR23737: Handle Atomic when rewriting Loads and Stores . philip.pfaffe updated this object. Comment Actions I don't think SROA is incorrect here. I'll comment on the bug, and we can sort out whether there is a bug here or not. However, even if there is a bug, we shouldn't turn *off* SROA due to atomics, we should just preserve atomicity when necessary. Specifically, if we can promote an alloca to an SSA variable, then only this thread references it, and so no synchronization could be occuring through the atomic accesses. We can (and should) add instcombine patterns to strip these kinds of atomic flags as well, but we often want SROA to work even without instcombine having run in order to minimize the runs necessary in the inliner/sroa iteration sequence.
Revision Contents
Diff 27192 lib/Transforms/Scalar/SROA.cpp
test/Transforms/SROA/atomic.ll
|