[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: PATCH libatomic
I am under the impression that (at least GCC) compilers will not emit
intrinsic calls if they are guaranteed to be available on the target.
This means libatomic needs to:
- Optimize: we can runtime detect, which emitted code cannot do.
Note that this means providing this libatomic will cause us to stop
noticing 64-bit atomics used when compiling for -march=i486, our default
for i386. We will stop upgrading those to -march=i586 and users will see
a performance penalty.
- Provide the fallback code
And that it isn't necessary for libatomic to:
- Attempt to cause the compiler to emit the intrinsic
Which should make this code a lot simpler.
+#define LOCK_FREE_ACTION(type) \
+ return atomic_compare_exchange_strong_explicit( \
+ (_Atomic(type) *)ptr, (type *)expected, *(type *)desired, success, \
This feels a bit offensive...
Mentally I am reading this as "I don't believe the compiler will
optimize out some scenarios in cleaner code with static inline, so
forcing the optimization to happen via C preprocessor".
I wonder if it's really true.
The macros seem overly complicated to avoid generics, I don't think
pre-C11 is a concern for us. I wonder if it can be simplified.
Main Index |
Thread Index |