similar to: [LLVMdev] Atomic operations: minimal or maximal?

On Mon, 3 Mar 2008, Andrew Lenharth wrote: > we have a large set of atomic ops that most platforms support natively > and the couple that don't can easily lower, or have a minimal set and > try to raise the lowered gcc atomic ops to efficient code on archs > that support ll/sc (essentially trying to recognize the ld, op, CAS > loops during codegen). I'd suggest starting

I was working on compare and swap and ran into the following problem. Several architectures implement this with a load locked, store conditional sequence. This is good, for those archs I can write generic code to legalize a compare and swap (and most other atomic ops) to load locked store conditional sequences (then the arch only had to give the instr for ldl, stc to support all atomic ops (this

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

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

Torvald Riegel wrote: > On Wednesday 20 February 2008 01:51, Andrew Lenharth wrote: >> Anyone have an idea? The patch as it stands is attached below. X86 >> is a pseudo instruction because the necessary ones and prefixes aren't >> in the code gen yet, but I would imagine they will be (so ignore that >> ugliness). The true ugliness can be seen in the alpha impl

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

On Wednesday 20 February 2008 01:51, Andrew Lenharth wrote: > Anyone have an idea? The patch as it stands is attached below. X86 > is a pseudo instruction because the necessary ones and prefixes aren't > in the code gen yet, but I would imagine they will be (so ignore that > ugliness). The true ugliness can be seen in the alpha impl which open > codes it, including a couple

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

On Thu, Jan 28, 2016 at 08:32:31AM -0800, Reid Kleckner via llvm-dev wrote: > I think Clang should continue to duplicate this information, the same way > we duplicate target datalayout strings. Other than that, sure, we can let > LLVM expand IR operations to libcalls. I don't immediately see a problem > with that. Note that a libcall doesn't necessarily mean using locks. With

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 Thu, Feb 21, 2008 at 9:34 AM, Andrew Lenharth <andrewl at lenharth.org> wrote: > 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

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

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

Attached is the target independent llvm.atomic.barrier support, as well as alpha and x86 (sse2) support. This matches Chandler's definitions, and the LangRef patch will just restore that. Non-sse2 barrier will be needed, I think it is "lock; mov %esp, %esp", but I'm not sure. Any objections? I'll take a hack at the front end support for __sync_synchronize after this

On 2/21/08, Chandler Carruth <chandlerc at gmail.com> wrote: > My strongest feeling is that "swap" has no place in an SSA IR, and the > idea of atomically loading, comparing, and storing is far more in > keeping. In fact, I thought the "swap" instrinsic had even been re-named > to "ls" for load-store at some point this summer.. Do you have those

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

Dear members of the list, I have difficulties to obtain sync with a Digium TE420 PCI Express For four entries E1, In my case I am with only 3 E1s available to configure. The telephony operator is BrasilTelecom and Signaling is R2 Digital. The information I have is that are E1s with 32 channels, not have sure. My settings Have been based on the link reference:

Dear all I would like to aggregate a data frame in a three minute interval. I have a time vector: > str(cas.param) `POSIXct', format: chr [1:181] "2003-06-12 09:00:00" "2003-06-12 09:01:00" "2003-06-12 09:02:00" and I want to turn it into a factor by cut. It works if I want to break it in let say hours > str(cut(cas.param,breaks="hour"))