[LLVMdev] Proposal for atomic and synchronization instructions

Scott Michel scottm at rushg.aero.org
Tue Jul 10 12:00:54 PDT 2007


Chris Lattner wrote:
> I think that Torvald's point here is that the idea/abstractions may be 
> reusable, not that the specific code or libraries can be reused.

I read Torvald's thesis as, "Why are you all reinventing the wheel? It's
already done, just incorporate atomic_ops!" After all, he actually used
the word, "reinventing".

Secondly, while atomic_ops may have interesting constructs and it may be
incorporated into the C++ standard (which is already too big and
unwieldy), my interpretation has been that LLVM is language-agnostic.

> While doing both of these, we want the model to be something that is 
> efficiently implementable on most architectures.  Not every operation has 
> to be equally efficient though: taking a spinlock to atomically update a 
> i1234 variable is probably ok. :)

Agreed. Updating a i1234 variable is treading dangerously into STM
territory... but I'll keep on the friggin' topic!

> Note that while LLVM doesn't have it's own -lllvm, it does use GCC's 
> libgcc.  libcc provides lib functions for things like "64-bit unsigned 
> rem" for targets that don't support it.  In 4.2, it also provides various 
> synch support features.  I think it would be useful to find out what it 
> provides, as we will want to be able to be compatible with it.

That's an artifact of having the GCC frontend and gcc's specific goal to
provide a consistent implementation of various data types across a large
cross section of platforms. It's not an artifact of LLVM. It may become
an issue for clang, but I doubt it because LLVM codegens the necessary
code to support 64 bit multiplication for platforms that don't have
native support.

The same argument applies to synch instructions. They may be needed to
support parts of the frontend, but that doesn't mean that there needs to
be additional external functionality or link artifacts to support them.

> While I know you're both trying to be helpful, please keep the discussion 
> obviously warm and friendly.  This is a widely read list, and not every 
> knows how surly and ornery you all are :)

I need to remind myself that fools must be suffered gladly. :-)


-scooter



More information about the llvm-dev mailing list