similar to: [LLVMdev] Proposal for atomic and synchronization instructions

Chandler Carruth wrote: > Hello, > > After a fair amount of research and work, I have put together a > concrete proposal for LLVM representations of atomic operations and > synchronization constructs. These aim to provide the minimal > functionality in the IR for representing the hardware constructs that > threading libraries and parallel programming rely on. > >

Hello, This is the second major revision of the atomic proposal for LLVM. I will try and give a brief overview of the motivating changes, but a greater portion of the text has changed, along with some changes to the proposed additions. http://chandlerc.net/llvm_atomics.html - The proposal has been rewritten to better delineate the goals and purposes of LLVM, and these additions to LLVM. The why

On 7/9/07, Andrew Lenharth <andrewl at lenharth.org> wrote: > Poor alpha, no code examples or entries in your tables. But that said, it uses a load-locked, store-conditional and has various memory barriers which are sufficient to implement all your proposal. Andrew > On 7/9/07, Chandler Carruth <chandlerc at gmail.com> wrote: > > Hello, > > > > After a fair

Here are some comments, quotes are from the draft. > an operation based constraint cannot guard other operations I think constraints associated with a particular instruction usually apply to this instruction and previous/subsequent instructions, so this wouldn't be true. This is the case in the atomic_ops model, and also on ia64 I think. > The single instruction constraints can,

On 7/12/07, Torvald Riegel <torvald at se.inf.tu-dresden.de> wrote: > Here are some comments, quotes are from the draft. > > > an operation based constraint cannot guard other operations > > I think constraints associated with a particular instruction usually apply > to this instruction and previous/subsequent instructions, so this wouldn't > be true. This is the

Poor alpha, no code examples or entries in your tables. Andrew On 7/9/07, Chandler Carruth <chandlerc at gmail.com> wrote: > Hello, > > After a fair amount of research and work, I have put together a > concrete proposal for LLVM representations of atomic operations and > synchronization constructs. These aim to provide the minimal > functionality in the IR for

Hi, I'd like to see support for something like this. I have some comments, and I think there is existing work that you can reuse. TAS and CAS are _not_ theoretically equivalent. TAS is weaker because it can solve consensus in a nonblocking way only for 2 threads (it has consensus number 2), whereas CAS can solve consensus for any number of threads (infinite consensus number).

> > > "While the processor may spin and attempt the atomic operation more than > > > once before it is successful, research indicates this is extremely > > > uncommon." I don't understand this sentence, what do you mean? > > > > I'm not sure I can pinpoint the paper from which the statement is based, > > but I seem to recall something

On 7/9/07, John Criswell <criswell at cs.uiuc.edu> wrote: > 1) You may want to consider adding atomic load-<bitwise operation>-store > instructions in addition to load-<add/subtract> instructions. The Linux > kernel uses these for atomic bit setting/clearing, and on many systems > they can be implemented more efficiently using special assembly > instructions.

Torvald Riegel wrote: > Hi, > > I'd like to see support for something like this. I have some comments, and I > think there is existing work that you can reuse. "reuse within the compiler." > "While the processor may spin and attempt the atomic operation more than once > before it is successful, research indicates this is extremely uncommon." > I

On Monday 09 July 2007 19:33, Scott Michel wrote: > Torvald Riegel wrote: > > Hi, > > > > I'd like to see support for something like this. I have some comments, > > and I think there is existing work that you can reuse. > > "reuse within the compiler." within the LLVM compiler framework, to be precise. > > > "While the processor may

That is good to hear. The lack of Alpha was purely a lack of time/knowledge of the architecture on my part, hopefully I can start learning some more about how it functions. If you send me either a pointer to appropriate documentation I would be happy to add appropriate information to the page. If you can provide implementations, it would save time, but I don't mind doing a fair portion of the

Torvald Riegel wrote: > On Monday 09 July 2007 19:33, Scott Michel wrote: >> Torvald Riegel wrote: >>> Hi, >>> >>> I'd like to see support for something like this. I have some comments, >>> and I think there is existing work that you can reuse. >> "reuse within the compiler." > > within the LLVM compiler framework, to be

On Tuesday 10 July 2007 01:38, Scott Michel wrote: > As Chandler pointed out, LL/SC isn't blocking. It belongs to the > optimistic concurrency class of constructs. One of the earliest papers > (IIRC, the first paper) on LL/SC was: > > Herlihy, M. 1993. A methodology for implementing highly concurrent data > objects. ACM Trans. Program. Lang. Syst. 15, 5 (Nov. 1993), 745-770.

On Mon, Jan 4, 2010 at 8:43 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Mon, Jan 4, 2010 at 1:13 PM, James Y Knight <foom at fuhm.net> wrote: >> Hi, thanks everyone for all the comments. I think maybe I wasn't clear that >> I *only* care about atomicity w.r.t. a signal handler interruption in the >> same thread, *not* across threads. Therefore,

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

On Jan 4, 2010, at 4:35 AM, Chandler Carruth wrote: > Responding to the original email... > > On Sun, Jan 3, 2010 at 10:10 PM, James Y Knight <foom at fuhm.net> wrote: >> In working on an LLVM backend for SBCL (a lisp compiler), there are >> certain sequences of code that must be atomic with regards to async >> signals. > > Can you define exactly what

On Mon, Jan 4, 2010 at 1:13 PM, James Y Knight <foom at fuhm.net> wrote: > Hi, thanks everyone for all the comments. I think maybe I wasn't clear that > I *only* care about atomicity w.r.t. a signal handler interruption in the > same thread, *not* across threads. Therefore, many of the problems of > cross-CPU atomicity are not relevant. The signal handler gets invoked via

On Mon, Jan 4, 2010 at 8:51 PM, Jeffrey Yasskin <jyasskin at google.com> wrote: > On Mon, Jan 4, 2010 at 8:43 PM, Chandler Carruth <chandlerc at google.com> wrote: >> On Mon, Jan 4, 2010 at 1:13 PM, James Y Knight <foom at fuhm.net> wrote: >>> Hi, thanks everyone for all the comments. I think maybe I wasn't clear that >>> I *only* care about

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