[LLVMdev] Proposal for atomic and synchronization instructions

Chris Lattner sabre at nondot.org
Tue Jul 10 12:15:16 PDT 2007


On Tue, 10 Jul 2007, Scott Michel wrote:
>> The idea is to review the atomic_ops model, and if it makes sense, just
>> reuse it. (e.g., atomic_ops seems to have (basic?) support for Alpha).
>
> atomic_ops may have interesting ideas on how Chandler might proceed and
> implement, but using its code is very unlikely.

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.

As I'm sure you know, the goal of the LLVM work is to provide the 
underlying facilities for synch that is lower-level than most user 
threading/synch libraries.  In terms of specific goals, I think it is 
useful to:

1. Support the GCC 4.2 synch builtins, since this is required for openmp
    (a nice easy-to-use user-level threading solution).
2. Provide sufficient synch builtins that other languages (e.g. the
    proposed C++ multithreading stuff, Java, etc) can have their synch
    needs met by LLVM.

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. :)

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.

>>> Seriously, I think that's the overall purpose for some of this work so
>>> that llvm can do a better job in instruction-level parallelism.
>> Can I get an answer to the actual question, please?
> Being argumentative for the sake of being argumentative isn't going to
> motivate me to answer your question. LLVM is a machine IR and its
>> Could we stay on topic, please?
> Bite me.

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 :)

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/



More information about the llvm-dev mailing list