Re: PATCH libatomic

[maya%NetBSD.org@localhost]

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,       \
+      failure)
+  LOCK_FREE_CASES();
+#undef LOCK_FREE_ACTION

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.