search for: crossthread

> On Nov 18, 2014, at 2:35 PM, Chandler Carruth <chandlerc at google.com> wrote: > > > On Fri, Nov 14, 2014 at 1:09 PM, Sahasrabuddhe, Sameer <sameer.sahasrabuddhe at amd.com <mailto:sameer.sahasrabuddhe at amd.com>> wrote: > 1. Update the synchronization scope field in atomic instructions from a > single bit to a wider field, say 32-bit unsigned integer.

On 11/19/2014 4:05 AM, Chandler Carruth wrote: > > On Fri, Nov 14, 2014 at 1:09 PM, Sahasrabuddhe, Sameer > <sameer.sahasrabuddhe at amd.com <mailto:sameer.sahasrabuddhe at amd.com>> > wrote: > > 1. Update the synchronization scope field in atomic instructions > from a > single bit to a wider field, say 32-bit unsigned integer. > > > I

...n)" for other scopes. 5. There is no keyword for cross-thread, but it can be specified as "synchscope(0)". This change breaks forward compatibility for the bitcode, since the meaning of the zero/one values are now changed. enum SynchronizationScope { - SingleThread = 0, - CrossThread = 1 + CrossThread = 0, + SingleThread = ~0U }; The change passes almost all lit tests including one new test (see patch 0005). The failing tests are specifically checking for forward compatibility: Failing Tests (3): LLVM :: Bitcode/cmpxchg-upgrade.ll LLVM :: Bitcode/memInstructio...

...e is no keyword for cross-thread, but it can be specified as > "synchscope(0)". > > This change breaks forward compatibility for the bitcode, since the > meaning of the zero/one values are now changed. > > enum SynchronizationScope { > - SingleThread = 0, > - CrossThread = 1 > + CrossThread = 0, > + SingleThread = ~0U > }; > > The change passes almost all lit tests including one new test (see patch > 0005). The failing tests are specifically checking for forward > compatibility: > > Failing Tests (3): > LLVM :: Bitcode/cmpxchg-u...

...tics on memory space 2, cst_seq semantics on address space 3". Also, unless I'm misreading on my skim of your proposal, the current definition of scope is slightly off from what you've specified. A "seq_cst singlethread" fence is a much weaker fence than a "seq_cst crossthread". It's probably easiest to reason about the current scheme as having the cross product of {singlethread, crossthread} x {orderings...} distinct orderings rather than a set of orderings with two overlapping scopes. Philip On 03/22/2016 01:42 PM, Ke Bai via llvm-dev wrote: > ​ ​ &gt...

Hi all, Currently, the LLVM IR uses a binary value (SingleThread/CrossThread) to represent synchronization scope on atomic instructions. We would like to enhance the representation of memory scopes in LLVM IR to allow more values than just the current two. The intention of this email is to invite comments on our proposal. There are some discussion before and it can be found...

...n the text format, because (a) there never was one and (b) it is not strictly needed since it is the default anyway. I am fine either way, but we will first have to decide what the new keyword should be. I find "allthreads" to be a decent counterpart for "singlethread" ... "crossthread" is not good enough since intermediate scopes have multiple threads too. This actually raises another question. In principle, the “most visible” scope ought to be something like “system” or “device”, meaning a completely uncached memory access that is visible to all peripherals in a heterog...

​​ Dear all, Here is the plain text version of the proposal: Currently, the LLVM IR uses a binary value (SingleThread/CrossThread) to represent synchronization scope on atomic instructions. We would like to enhance the representation of memory scopes in LLVM IR to allow more values than just the current two. The intention of this email is to invite comments on our proposal. There are some discussion before and it can be found...

> On Apr 18, 2016, at 9:12 AM, Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Here is the initial proposal with some formatting fixed: > > Currently, the LLVM IR uses a binary value (SingleThread/CrossThread) to > represent synchronization scope on atomic instructions. We would like to > enhance the representation of memory scopes in LLVM IR to allow more values > than just the current two. The intention of this email is to invite > comments on our proposal. There are some discussion before...

...never was one > and (b) it is not strictly needed since it is the default anyway. > I am fine either way, but we will first have to decide what the > new keyword should be. I find "allthreads" to be a decent > counterpart for "singlethread" ... "crossthread" is not good > enough since intermediate scopes have multiple threads too. > > This actually raises another question. In principle, the “most > visible” scope ought to be something like “system” or “device”, > meaning a completely uncached memory access that is...

Hi All, Does anyone know of a decent itsp that can provide a Scottsdale, Arizona DID, preferably with no 'plan' but just minutes used? Thanks, Tim

How embarassing. This was not meant for the list. My apologies.. Tim -------- Original Message -------- Subject: Re: [Asterisk-Users] Set voicemail maximum length by context Date: Thu, 18 Aug 2005 13:17:15 -0600 From: Tim Pushor <timp@crossthread.com> Reply-To: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users@lists.digium.com> To: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users@lists.digium.com> References: <015801c5a40b$d07262c0$8464a8c0@kc.visioninc.com> <4304B7E...

...paque string-based scope effectively. If we can find > a reasonably clean way of doing it, it seems like the best approach at > this point: > > - It ensures we have no bitcode stability problems. > - It makes it easy to define a small number of IR-specified values > like system/crossthread/allthreads/whatever and singlethread, and > doing so isn't ever awkward due to any kind of baked-in ordering. > - In practice in the real world, every target is probably going to > just take this and map it to an enum that clearly spells out the rank > for their target, so I susp...

...gium.com/mailman/listinfo/asterisk-users >To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users > > > > > >------------------------------ > >Message: 3 >Date: Sun, 27 Mar 2005 11:51:55 -0800 >From: Tim Pushor <timp@crossthread.com> >Subject: Re: [Asterisk-Users] How to use multiple VOIP provider trunks >To: Asterisk Users Mailing List - Non-Commercial Discussion > <asterisk-users@lists.digium.com> >Message-ID: <42470EDB.900@crossthread.com> >Content-Type: text/plain; charset=ISO-8859-1; form...

...t;") { return Insert(new FenceInst(Context, Ordering, SynchScope), Name); } - AtomicCmpXchgInst *CreateAtomicCmpXchg(Value *Ptr, Value *Cmp, Value *New, - AtomicOrdering Ordering, - SynchronizationScope SynchScope = CrossThread) { - return Insert(new AtomicCmpXchgInst(Ptr, Cmp, New, Ordering, SynchScope)); + AtomicCmpXchgInst * + CreateAtomicCmpXchg(Value *Ptr, Value *Cmp, Value *New, + AtomicOrdering SuccessOrdering, + AtomicOrdering FailureOrdering, + S...

...the notion of memory scope in atomic operations to global memory. These scopes are a hint to the underlying platform to optimize how synchronization is achieved. HSAIL also has a notion of memory scopes that is compatible with OpenCL 2.0. Currently, the LLVM IR uses a binary value (SingleThread/CrossThread) to represent synchronization scope on atomic instructions. This makes it difficult to translate OpenCL 2.0 atomic operations to LLVM IR, and also to implement HSAIL memory scopes in the proposed HSAIL backend for LLVM. We would like to enhance the representation of memory scopes in LLVM IR to...

Hi All, I am having trouble with receiving calls from FWD via IAX. I know this isn't a FWD support forum, but I suspect the problem is my asterisk setup. The problem is that I can dial out to fwd subscribers, even myself but they can't dial me using my FWD number. I don't know much about IAX, but it would seem to me like a registration problem, but I get no errors or warnings in

...henever they call me I tell > them that I don't have an extension/context by the name they dialed. > > Any ideas? > -- Mark, G7LTT/KC2ENI Randolph, NJ http://www.g7ltt.com ------------------------------ Message: 17 Date: Mon, 18 Jul 2005 10:22:27 -0600 From: Tim Pushor <timp@crossthread.com> Subject: [Asterisk-Users] Codecs and bandwidth To: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users@lists.digium.com> Message-ID: <42DBD743.80803@crossthread.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi Friends, Something I'd l...

Hi All, I am trying to figure out how Asterisk determines which [user] an incoming IAX connection is for? Is it based on their source address? (I think possible) Is it based on their credentials (unlikely, I think, since we can set insecure=very) Also, for a [peer] section - when is the host= resolved? Is name resolution attempted every time the channel is opened? Thanks! Tim (Oh and sorry