This is an archive of the discontinued LLVM Phabricator instance.

[compiler-rt][builtins] Tweak checks for lock-free atomics
AbandonedPublic

Authored by luismarques on Aug 20 2020, 5:24 AM.

Details

Summary

The IS_LOCK_FREE_* macros in atomic.c were using the __c11_atomic_is_lock_free builtin. Those specific builtin calls would typically be lowered to compile-time constants (probably for all of the scenarios where compiler-rt was being used and providing atomic builtins). In some cases, though, the builtin can be lowered to a call to the runtime function __atomic_is_lock_free. An example is when targeting RISC-V rv32imac and it calls __c11_atomic_is_lock_free(8) by using the IS_LOCK_FREE_8 macro. Yet, atomic.c doesn't provide an implementation of __atomic_is_lock_free. In those scenarios you aren't able to link your program. To address this issue, this patch changes the macros to be implemented in terms of the __atomic_always_lock_free builtin, which is always lowered to a compile-time constant.

An alternative approach would be to implement the run-time function __atomic_is_lock_free, but right now that would only add run-time overhead. atomic.c implements the builtin runtime functions in terms of other atomic builtins, but the only relevant builtin here is __atomic_always_lock_free, so you might as well just use that builtin in the first place. If compiler-rt started to deviate from the current implementation approach and providing architecture-specific logic it's theoretically possible that a more fine-grained implementation of __atomic_is_lock_free could allow covering additional cases with lock-free implementations. If that ever comes to pass, we can revisit the implementation of the macros changed by this patch.

(This review supersedes D86043, due to issues with subscribing llvm-commits).

Diff Detail

Event Timeline

luismarques created this revision.Aug 20 2020, 5:24 AM
Herald added a project: Restricted Project. · View Herald TranscriptAug 20 2020, 5:24 AM
Herald added subscribers: Restricted Project, s.egerton, PkmX and 3 others. · View Herald Transcript
arichardson accepted this revision.Aug 25 2020, 12:51 AM
arichardson added a subscriber: arichardson.

Only just saw this after posting my own fix (D86510). This LGTM, and I can rebase my change to enable the 16-byte case on top of this.

This revision is now accepted and ready to land.Aug 25 2020, 12:51 AM
arichardson added inline comments.Aug 25 2020, 1:21 AM
compiler-rt/lib/builtins/atomic.c
124

Actually, I'm not sure if passing NULL is correct, can __atomic_load be called with an under-aligned pointer?

luismarques abandoned this revision.Aug 25 2020, 1:31 AM

Only just saw this after posting my own fix (D86510). This LGTM, and I can rebase my change to enable the 16-byte case on top of this.

Great minds think alike ;)
Your patch is a superset of mine, so we can just apply yours. I'll abandon this one.

Abandoning. Superceeded by D86510.

luismarques added inline comments.Aug 25 2020, 4:59 AM
compiler-rt/lib/builtins/atomic.c
124

Good question. At the time when I reasoned about that issue I concluded that it was correct. I remember checking that the assembly ouput of compiling atomic.c didn't change at all for e.g. X86 (that doesn't prove anything for the general case, but it's still a good sanity check). But thinking again about it I think you may be right -- or maybe I'm just forgetting the reasons why I had concluded it was fine. It doesn't matter now :)