This is an archive of the discontinued LLVM Phabricator instance.

[Atomics] warn about misaligned atomic accesses using libcalls
ClosedPublic

Authored by t.p.northover on Apr 5 2018, 6:21 AM.

Details

Reviewers
rsmith
compnerd
Summary

If an atomic variable is misaligned Clang will emit accesses to it as a libcall. These calls are likely to be slow and involve locks; they are almost certainly not what the developer intended. So this patch adds a warning (promotable or ignorable) for tat situation.

Diff Detail

Repository
rC Clang

Event Timeline

t.p.northover created this revision.Apr 5 2018, 6:21 AM
compnerd accepted this revision.Apr 14 2018, 11:23 AM
compnerd added a subscriber: compnerd.

Sorry for the delay, didn't see the changes earlier.

clang/lib/CodeGen/CGAtomic.cpp
886

It is kinda unfortunate that you need to look up 125 lines to get the context that the call here is implied by a lack of alignment. Perhaps we can rename UseLibcall to UnsuitableAligned or something?

This revision is now accepted and ready to land.Apr 14 2018, 11:23 AM
t.p.northover added inline comments.Apr 19 2018, 6:25 AM
clang/lib/CodeGen/CGAtomic.cpp
886

I'd be OK with that, or I could just move the diagnostic further up so it is next to the definition (or maybe just after to avoid the atomic_init case)?

compnerd added inline comments.Apr 19 2018, 5:46 PM
clang/lib/CodeGen/CGAtomic.cpp
886

That addresses my concern too, the choice is yours :-)

Moved diagnostic emission next to where the decision is made.

t.p.northover closed this revision.Apr 23 2018, 1:19 AM

Ah, I see you approved it before, presumably with the suggested changes. I've committed as r330566.

There's still something wrong here: in the cases where we produce these warnings, we still produce calls to __atomic_*_<n> library functions. Those functions are specified to only work on properly-aligned inputs, so that's wrong. And there seems to be a problem with alignment in compiler-rt too: the "unoptimized" __atomic_load_n implementation only looks at the size and not the alignment of the pointer when determining whether to use a lock.

See also PR38846.