[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