jyknight requested changes to this revision.
jyknight added a comment.
This revision now requires changes to proceed.
This isn't correct.
The atomic interface is designed to be forward-compatible with new CPUs that
have wider atomic instructions. That clang has a MaxAtomicPromoteWidth value
MaskRay added a comment.
From https://gcc.gnu.org/ml/gcc/2020-02/msg00116.html
> We discussed this on IRC in #gcc. There was no motivation to change GCC. The
> platform that wants to avoid the libatomic dependency doesn't use GCC anyway.
> Relying on not getting the libatomic dependency seems
efriedma added a comment.
Eagerly evaluating based on MaxAtomicPromoteWidth seems fine... assuming we're
actually setting MaxAtomicPromoteWidth to something appropriate. The value on
PowerPC looks wrong.
If we're worried about constant-evaluating it in contexts where gcc doesn't, we
can
jfb added a subscriber: jwakely.
jfb added a comment.
This changes the expression to a constant expression as well, right? You should
point this out in the commit message.
The divergence with GCC is unfortunate, @jwakely do you think you'd be able to
get GCC to match this behavior as well?
nemanjai added a comment.
If I understand this correctly, this just evaluates the query for lock free
atomics at compile time if the size is larger than the maximum possible size
for an atomic on the target. If that's the case, this looks fine to me. But of
course, some of the other target
merge_guards_bot added a comment.
{icon check-circle color=green} Unit tests: pass. 61771 tests passed, 0 failed
and 780 were skipped.
{icon times-circle color=red} clang-tidy: fail. Please fix clang-tidy findings
MaskRay created this revision.
MaskRay added reviewers: adalava, dim, nemanjai, jfb, rsmith.
Herald added subscribers: cfe-commits, steven.zhang, dexonsmith, krytarowski,
arichardson, emaste.
Herald added a project: clang.
MaxAtomicPromoteWidth is defined as "the maximum width lock-free atomic
