similar to: [LLVMdev] Atomic Operation and Synchronization Proposal v2

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

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. http://chandlerc.net/llvm_atomics.html While I am no expert on the

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

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

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

> > > "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 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 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.

On Thursday 12 July 2007 07:23, Torvald Riegel wrote: > > The single instruction constraints can, at their most flexible, constrain > > any set of possible pairings of loads from memory and stores to memory > > I'm not sure about this, but can we get issues due to "special" kinds of > data transfers (such as vector stuff, DMA, ...?). Memcpy implementations >

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

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

On Thu, Jul 12, 2007 at 10:06:04AM -0500, David Greene wrote: > On Thursday 12 July 2007 07:23, Torvald Riegel wrote: > > > > The single instruction constraints can, at their most flexible, constrain > > > any set of possible pairings of loads from memory and stores to memory > > > > I'm not sure about this, but can we get issues due to "special"

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

On 2/21/08, Torvald Riegel <torvald at se.inf.tu-dresden.de> wrote: > why is the intrinsic name not CAS? And having another version that returns > just a bool might be better in some cases ( 1. does CAS return the value on > all architectures? 2. you can just jump based on a flag and don't need to > compare it again). Just my 2 cents though ... I was going from

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

On Tuesday 13 July 2010 19:48:25 you wrote: > On Tue, Jul 13, 2010 at 10:09 AM, Torvald Riegel > > I thought that the layout of structs was supposed to be preserved (wrong > > assumption?). Otherwise, any ideas why this happens? > > It should be preserved in general; Is this a "should" or a "must"? Are there any cases in which structure layout must be

On Wed, Jul 14, 2010 at 3:20 AM, Torvald Riegel <torvald at se.inf.tu-dresden.de> wrote: > On Tuesday 13 July 2010 19:48:25 you wrote: >> On Tue, Jul 13, 2010 at 10:09 AM, Torvald Riegel >> > I thought that the layout of structs was supposed to be preserved (wrong >> > assumption?). Otherwise, any ideas why this happens? >> >> It should be preserved in