[LLVMdev] Atomic Operation and Synchronization Proposal v2

[Chandler Carruth]

Hello,

This is the second major revision of the atomic proposal for LLVM. I
will try and give a brief overview of the motivating changes, but a
greater portion of the text has changed, along with some changes to
the proposed additions.

http://chandlerc.net/llvm_atomics.html

- The proposal has been rewritten to better delineate the goals and
purposes of LLVM, and these additions to LLVM. The why and to what
purpose has been a source of confusion, and this is addressed
directly.
- The explanation of memory barriers and why the representation was
chosen has been reworked to address concerns raised.
- The explanation of load-linked, store-conditionally atomic
operations has been expanded and reworded to be more clear and
precise. The paper to investigate theoretical details in has been
added to the references.
- Both the hardware survey, and all implementation tables have been
updated to include Alpha architecture stuff.
- The entire set of additions has been moved to intrinsic functions
instead of instructions. If these merit and can benefit from moving up
to instructions, they may, but this eases the implementation burden
significantly.
- The types supported have been narrowed to only integers. The sizes
of integers supported is determined by the target implementation.
- GCC builtins have been added with rough outlines of how they could
be lowered to the proposed intrinsic functions.
- Other minor (and not-so-minor) cosmetic cleaning took place to make
these integrate smoothly and present a more cohesive proposal.

A few things were not changed because they can easily be added later
if and when desired, and would complicate the initial implementation.
Incremental is good!

- Vector type support
- Other type support
- Acquire and release implied memory constraints on atomic operations

This revision grew directly out of the feedback provided. Please
continue to review this, and hopefully we will see a first rate
representation of these constructs in LLVM soon.

Thank you again,
-Chandler Carruth