This is an archive of the discontinued LLVM Phabricator instance.

[SROA] Fix for PR23737: Handle Atomic when rewriting Loads and Stores
AbandonedPublic

Authored by philip.pfaffe on Jun 5 2015, 5:42 AM.

Details

Reviewers
chandlerc
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 Timeline

philip.pfaffe retitled this revision from to [SROA] Fix for PR23737: Handle Atomic when rewriting Loads and Stores .
philip.pfaffe updated this object.
philip.pfaffe edited the test plan for this revision. (Show Details)
philip.pfaffe added a reviewer: chandlerc.
philip.pfaffe set the repository for this revision to rL LLVM.
philip.pfaffe added a subscriber: Unknown Object (MLST).

This looks reasonable to me but I'd like to know how Chandler feels about this.

chandlerc edited edge metadata.Jul 10 2015, 11:39 PM

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.

philip.pfaffe abandoned this revision.Mar 17 2016, 5:23 AM

This has been superseded by rL242126.