[refactor] simplify the definition of atomic functions

[gasche]

In trunk, all atomic functions exposed in the runtime are also exposed as language primitives in our intermediate representations (lambda, clambda). But except for Patomic_load, which benefits from dedicated code generation, they are all transformed into C calls on all backends.

The present PR simplifies the code noticeably by removing the intermediate primitives, by producing C calls directly in lambda/translprim.ml.

This reduces the amount of boilerplate to modify to implement atomic record fields (ocaml/RFCs#39).

[kayceesrk]

LGTM.

[OlivierNicole]

But except for Patomic_load, which benefits from dedicated code generation, they are all transformed into C calls on all backends.

I am wondering whether we should make more atomic operations like Patomic_load. I just opened #13403 to track that discussion, not for the sake of being contrarian, but because I’ve been putting it off for a while and this PR prompted me to express it.

[kayceesrk]

My feeling is that we should go ahead with this PR to simplify the implementation of ocaml/RFCs#39. The code being removed here is mostly boilerplate and can be added back if certain operations in Atomic module need to be inlined.

[OlivierNicole]

I agree that it is probably best not to block this simplification PR and discuss #13403 independently.

[lthls]

If you're using C calls immediately, is there any reason to keep the definition as %-primitives ? I would change atomic.ml to use the C primitives directly, that would save you the trouble of defining them manually in Translprim.

[gasche]

@OlivierNicole one obvious downside of "compiling to one or two instructions" is that we now have to maintain one compilation scheme for each of those operations, for each backend. We can arguably just copy whatever gcc/clang are doing, but this is extra work and maintenance. Is there a clear performance case for doing this extra work?

@lthls I considered doing this. But having the %foo primitive around gives us slightly more freedom to change the implementation strategy without touching the stdlib (or possibly, third-party code): we can change back and forth between primitives and C calls without changing OCaml code at all. Given the very small maintenance cost of the %foo blurb, I think this is a good compromise.

[gasche]

Is there a clear performance case for doing this extra work?

More precisely, my suggestion is to try to find a program whose bottleneck are atomic operations, implement backend support for just one backend for the atomic you care about, and see if there is a measurable benefit.

[gasche]

Thanks everyone! I fully agree with @kayceesrk' assessment :-) and propose to merge right away.