llvm dev - Jul 2007 - [LLVMdev] Proposal for atomic and synchronization instructions

Torvald Riegel wrote:
> First of all, I know LL/SC. Did I say it's equivalent to get-and-set?
No.
> So what are you trying to say, why is the paragraph in the proposal? You 
> seem to be speculating about architectures in general in one paragraph. 
> IMHO, I wouldn't try that, because I would have to be either imprecise
or
> don't state anything new.
I was rebutting your point regarding spin locks going through the loop
once; spinning for more than one iteration is generally rare. And no, I
am not speculating about architectures in general, for that matter. I
simply like LL/SC and think it's superior to most other primitives,
being a matter of good taste.

BTW: It's not my proposal. I merely work with Chandler.
>>> Please have a real look at atomic_ops first. It does have a library
>>> part to it -- but that's just for a nonblocking stack.
>> It's a lot like Apple's (and gcc's) work to reconcile the
Intel and PPC
>> vector intrinsics. Nice work but an unnecessary dependency, in my
>> personal and not so humble opinion.
> 
> So when you are reinventing the wheel, it doesn't give you a dependency
on
> the wheel, is that what you're saying?
No. I'm not saying that at all. If you actually took a look at LLVM,
you'd notice that it stands alone. It has very few dependencies upon
outside code and it generates __no__ dependencies to outside code or
libraries. From previous experience developing for LLVM, I happen to
know that unnecessary dependencies are not viewed favorably.
> 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.
>>> Second, I guess there has been some serious effort put into
selecting
>>> the specific model. So, for example, if you look at some of
Hans'
>>> published slides etc., there are some arguments in favor of
associating
>>> membars with specific instructions. Do you know reasons why LLVM
>>> shouldn't do this?
>> You mean the papers that don't have to do with garbage collection?
:-)
>>
>> 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
instructions have to map to something that exists and has reasonable
properties. Asking for acquire/release, which only exists on one
architecture, doesn't fit the pattern (and is arguably not such a great
idea within that particular implementation.)
> Could we stay on topic, please?
Bite me.


-scooter

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

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/