[LLVMdev] Proposal for atomic and synchronization instructions

[Scott Michel]

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