search for: synchscope

...behavior. The proposed syntax for synchronization scope is as follows: - Synchronization scopes are of arbitrary width, but implemented as unsigned in the bitcode, just like address spaces. - Cross-thread is default. - Keyword "singlethread" is unchanged - New syntax "synchscope(n)" for other target-specific scopes. - There is no keyword for cross-thread, but it can be specified as "synchscope(0)". The proposed new integer implementation expanded synchronization scopes are as follows: *Format* *Single Thread* *System (renamed)* *Intermediate* *Bitcode...

...is the current behavior. The proposed syntax for synchronization scope is as follows: * Synchronization scopes are of arbitrary width, but implemented as unsigned in the bitcode, just like address spaces. * Cross-thread is default. * Keyword "singlethread" is unchanged * New syntax "synchscope(n)" for other target-specific scopes. * There is no keyword for cross-thread, but it can be specified as "synchscope(0)". The proposed new integer implementation expanded synchronization scopes are as follows: **************************************************************** Format ​...

...The proposed syntax for synchronization scope is as follows: > * Synchronization scopes are of arbitrary width, but implemented as > unsigned in the bitcode, just like address spaces. > * Cross-thread is default. > * Keyword "singlethread" is unchanged > * New syntax "synchscope(n)" for other target-specific scopes. > * There is no keyword for cross-thread, but it can be specified as > "synchscope(0)". > > The proposed new integer implementation expanded synchronization > scopes are as follows: > ******************************************...

...The proposed syntax for synchronization scope is as follows: > * Synchronization scopes are of arbitrary width, but implemented as > unsigned in the bitcode, just like address spaces. > * Cross-thread is default. > * Keyword "singlethread" is unchanged > * New syntax "synchscope(n)" for other target-specific scopes. > * There is no keyword for cross-thread, but it can be specified as > "synchscope(0)". Why not going with a metadata attachment directly and kill the "singlethread" keyword? Something like: Something like: cmpxchg i32* %addr...

...Value Ptr, SDValue Cmp, SDValue Swp, MachinePointerInfo PtrInfo, unsigned Alignment, - AtomicOrdering Ordering, + AtomicOrdering SuccessOrdering, + AtomicOrdering FailureOrdering, SynchronizationScope SynchScope); SDValue getAtomic(unsigned Opcode, SDLoc dl, EVT MemVT, SDValue Chain, SDValue Ptr, SDValue Cmp, SDValue Swp, MachineMemOperand *MMO, - AtomicOrdering Ordering, + AtomicOrdering SuccessOrdering, +...

...called !nosynch that lists a set of "domains" a > certain memory operation does *not* synchronize with. > > - Memory operations with !nosynch synchronize with memory operations > without any !nosynch metadata (so dropping !nosynch is safe). I’m not sure, but isn’t the synchscope id (or domains as you seem to call it) intended to change which instruction would be actually codegen? In which case I’m not sure dropping it is ever a good idea, even when it does not affect correctness it would dramatically affect performance. — Mehdi > > This will only work if your f...

...are of arbitrary width, but implemented as unsigned in the bitcode, just like address spaces. 2. Cross-thread is default, but now encoded as 0. 3. Keyword 'singlethread' is unchanged, but now encoded as the largest integer (which happens to be ~0U in bitcode). 4. New syntax "synchscope(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, -...

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

...lemented as > unsigned in the bitcode, just like address spaces. > 2. Cross-thread is default, but now encoded as 0. > 3. Keyword 'singlethread' is unchanged, but now encoded as the > largest integer (which happens to be ~0U in bitcode). > 4. New syntax "synchscope(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 Synchronizatio...

...without Philip’s opinion on the topic as he expressed concerns). But you stripped out the second part of my email where I wrote "It seems you’re going back to integer, which I don’t really like for reasons mentioned earlier in this thread, and that I don’t feel you addressed here”. Why can’t `synchscope` take a string literal? — Mehdi > > > From: Zhuravlyov, Konstantin > Sent: Wednesday, August 17, 2016 4:29:30 PM > To: Sameer Sahasrabuddhe; Philip Reames > Cc: Mehdi Amini; Liu, Yaxun (Sam); Ke Bai; Mekhanoshin, Stanislav; Sumner, Brian; llvm-dev at lists.llvm.org; Tye...

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

...change: ==================== --- a/include/llvm/CodeGen/SelectionDAGNodes.h +++ b/include/llvm/CodeGen/SelectionDAGNodes.h @@ -1068,6 +1068,7 @@ public: /// class AtomicSDNode : public MemSDNode { SDUse Ops[4]; + SDUse buffer; void InitAtomic(AtomicOrdering Ordering, SynchronizationScope SynchScope) { // This must match encodeMemSDNodeFlags() in SelectionDAG.cpp. ==================== -- makes LLVM fail 83 regression tests, basically everything related to the atomic ops, in a bunch of unrelated ways: some segfaults, some failing assertions, some wrong outputs, all suggesting there's...

Hi Tim, On 20 November 2017 at 16:41, Tim Northover <t.p.northover at gmail.com> wrote: > There are only a couple of valid uses for volatile these days Do you mean volatile used alone or also the combination 'atomic volatile'? It think that 'atomic volatile' is very useful. Consider following pseudo-code examples, where all loads and stores are atomic (with some memory

...s "address space scope", i.e., all threads that can access the address space being accessed. From that view, it does not matter if the threads are local, remote or situated on different devices, or such. It makes sense to not specify any keyword for this scope, and just say that "synchscope(0)" is default and need not be specified. Any other scope is an explicit optimization over a narrower set of threads. > As a related question, do we actually need the local scopes to be > target specific? Are there systems, real or planned, that > *aren’t* captured by:...

...{ MVT::v2i32, MVT::Other }; > + SDVTList VTList = { VTs.data(), VTs.size() }; > + > + SDValue CmpSwap = DAG.getMemIntrinsicNode(AMDGPUISD::CMP_SWAP, DL, VTList, > + Ops, MemVT, Swap->getMemOperand()); > + // TODO: What about ordering? synchscope? > + > + // Extract returned old value > + SDValue Zero = DAG.getConstant(0, DL, MVT::i32); > + SDValue Old = DAG.getNode(ISD::EXTRACT_VECTOR_ELT, DL, MVT::i32, > + CmpSwap.getValue(0), Zero); > + > + // Merge return value and Chain > + SDVa...

> Since the scope is “opaque” and target specific, can you elaborate what kind of generic optimization can be performed? Some optimizations that are related to a single thread could be done without needing to know the actual memory scope. For example, an atomic acquire can restrict reordering memory operations after it, but allow reordering of memory operations (except another atomic acquire)

Hi Tom, Matt, I'm working on a project that needs few coherent atomic operations (HSA mode: load, store, compare-and-swap) for std::atomic_uint in HCC. the attached patch implements atomic compare and swap for SI+ (untested). I tried to stay within what was available, but there are few issues that I was unsure how to address: 1.) it currently uses v2i32 for both input and output. This

...final pass through if no one else has first. >> >> But you stripped out the second part of my email where I wrote "It seems you’re going back to integer, which I don’t really like for reasons mentioned earlier in this thread, and that I don’t feel you addressed here”. Why can’t `synchscope` take a string literal? >> >> >> — >> Mehdi >> >> >> >> >> >>> >>> >>> From: Zhuravlyov, Konstantin >>> Sent: Wednesday, August 17, 2016 4:29:30 PM >>> To: Sameer Sahasrabuddhe; Philip Ream...

Hi, I have updated the review here: https://reviews.llvm.org/D21723 As Sameer pointed out, the motivation is: In OpenCL 2.x, two atomic operations on the same atomic object need to have the same scope to prevent a data race. This derives from the definition of "inclusive scope" in OpenCL 2.x. Encoding OpenCL 2.x scope as metadata in LLVM IR would be a problem because there cannot be a

Hi Sameer, > On Jan 5, 2015, at 4:51 AM, Sahasrabuddhe, Sameer <Sameer.Sahasrabuddhe at amd.com> wrote: > > Right. The second version of my patches fixes the bitcode encoding. But now I see another potential problem with future bitcode if we require an ordering on the scopes. What happens when a backend later introduces a new scope that goes into the middle of the order? If they