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
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? |
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)? |
clang/lib/CodeGen/CGAtomic.cpp | ||
---|---|---|
886 | That addresses my concern too, the choice is yours :-) |
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.
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?