This is an archive of the discontinued LLVM Phabricator instance.

[sanitizer] Correct 64-bit atomic_store on 32-bit "other" platforms
ClosedPublic

Authored by cryptoad on May 8 2018, 1:01 PM.

Details

Summary

I think there might be something to optimize in atomic_store.
Currently, if everything goes well (and we have a different new value), we
always iterate 3 times.
For example, with a = 0, oldval = a, newval = 42, we get:

oldval = 0, newval = 42, curval = 0  
oldval = 0, newval = 42, curval = 42 
oldval = 42, newval = 42, curval = 42

and then it breaks.

Unless I am not seeing something, I don't see a point to the third iteration.
If the current value is the one we want, we should just break.
This means that 2 iterations (with a different newval) should be sufficient to
achieve what we want.

Diff Detail

Repository
rL LLVM

Event Timeline

cryptoad created this revision.May 8 2018, 1:01 PM
Herald added subscribers: Restricted Project, delcypher, kubamracek. · View Herald TranscriptMay 8 2018, 1:01 PM
dvyukov added inline comments.May 9 2018, 1:05 AM
lib/sanitizer_common/sanitizer_atomic_clang_other.h
89 ↗(On Diff #145763)

The current is not just slow, it looks broken to me. Is it even used anywhere? Maybe we should just drop it. I think we generally require C++11 for building compiler-rt.

The canonical way to do this is cur == cmp which should accomplish the operation with 1 CAS in common case. The old check was probably an attempt to optimize for the case when the variable already contains the value we want to store (and we obtained an atomic snapshot of the current value with CAS). So perhaps this could be cur == cmp || cur == v?

cryptoad added inline comments.May 9 2018, 7:16 AM
lib/sanitizer_common/sanitizer_atomic_clang_other.h
89 ↗(On Diff #145763)

Unfortunately yes this is used for ARM32, when doing a 64-bit atomic store.
I noticed that on some platforms this was particularly slow hence me chasing down what could go wrong.
I'd like to keep using this to not have a libc++ (or equivalent) dependency (for Scudo at least).
I'll apply the suggested change, thanks!

cryptoad updated this revision to Diff 145928.May 9 2018, 8:20 AM
cryptoad marked 2 inline comments as done.

Changing the break condition to Dmitry's suggestion.

dvyukov accepted this revision.May 9 2018, 9:10 AM
This revision is now accepted and ready to land.May 9 2018, 9:10 AM
This revision was automatically updated to reflect the committed changes.