search for: singlethread

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

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

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

...the lines of "acquire semantics on memory space 1, release semantics 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. Ph...

...s need to be > precluded as the control flow within the hardware thread may > arbitrarily move from one sequence of instructions to another. > > If it is required in > target-independent transforms, > > > Yes, it is. sig_atomic_t. Thanks! This also explains why SingleThread is baked into tsan. I couldn't find a way to work around __tsan_atomic_signal_fence if I removed SingleThread as a well-known memory scope. > > 5. Possibly add the following constraint on memory scopes: "The scope > represented by a larger value is nested inside (is a...

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

...ge is that it makes it much harder to accidentally > write code that relies on the particular values for the integers. =] Here's what this looks like to me: 1. LLVM text format will use string symbols for memory scopes, and not numbers. The set of strings is target defined, but "singlethread" and "system" are reserved and have a well-known meaning. 2. "The keyword informally known as system" represents the set of all threads that could possibly synchronize on the location being accessed by the current atomic instruction. These threads could be...

...or emitting atomic instructions via Clang. The proposed syntax for synchronization scope is as follows: 1. Synchronization scopes 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 compatibilit...

...----------------------------------- This proposal introduces new sets of intrinsics, two load intrinsics and two store intrinsics. The sets are as follows: declare <type> @llvm.portable.load.e.<type>(<type>* ptr, , i32 alignment, i1 host, i1 atomic, i1 volatile, i1 nontemporal, i1 singlethread) // little endian load declare <type> @llvm.portable.load.E.<type>(<type>* ptr, i32 alignment, i1 host, i1 atomic, i1 volatile, i1 nontemporal, i1 singlethread) // big endian load declare void @llvm.portable.store.e.<type>(<type> data, <type>* ptr, i32 alignme...

.... The other atomic operations are not affected, so I'd like to add a second ordering operand to "cmpxchg" to support the full range of possible requests. The suggested syntax would be cmpxchg [volatile] <ty>* <pointer>, <ty> <cmp>, <ty> <new> [singlethread] <success ordering> <failure ordering> That is, syntactically I propose: + No comma between the two + Both operands are required, even if "failure" is the natural pair of "success" Semantically, I would like to enforce the constraints in the standards: + fail...

...ang. > > The proposed syntax for synchronization scope is as follows: > > 1. Synchronization scopes 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 ch...

...word for cross thread scope in 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...

Hi all, On 02.05.2016 17:46, Tom Stellard via llvm-dev wrote: >> Why not going with a metadata attachment directly and kill the "singlethread" keyword? Something like: >> >Something like: >> > >> > cmpxchg i32* %addr, i32 42, i32 0 monotonic monotonic, 3, !memory.scope{!42} >> > cmpxchg i32* %addr, i32 42, i32 0 monotonic monotonic, 3, !memory.scope{!43} >> > >> >... >> &...

...------------------------- --- This proposal introduces new sets of intrinsics, two load intrinsics and two store intrinsics. The sets are as follows: declare <type> @llvm.portable.load.e.<type>(<type>* ptr, , i32 alignment, i1 host, i1 atomic, i1 volatile, i1 nontemporal, i1 singlethread) // little endian load declare <type> @llvm.portable.load.E.<type>(<type>* ptr, i32 alignment, i1 host, i1 atomic, i1 volatile, i1 nontemporal, i1 singlethread) // big endian load declare void @llvm.portable.store.e.<type>(<type> data, <type>* ptr,...

...he at amd.com <mailto:sameer.sahasrabuddhe at amd.com>> > wrote: > > Here's what this looks like to me: > > 1. LLVM text format will use string symbols for memory scopes, > and not numbers. The set of strings is target defined, but > "singlethread" and "system" are reserved and have a well-known > meaning. > > 2. "The keyword informally known as system" represents the set of > all threads that could possibly synchronize on the location > being accessed by the current atomic...

...pasted a 80-column safe text version > > below. > > > > A second smaller set could be: > > declare <type> @llvm.portable.load.<type>(<type>* ptr, i32 alignment, > > i1 host, i1 littleEndian, i1 atomic, i1 volatile, > > i1 nontemporal, i1 singlethread) > > > > declare void @llvm.portable.store.<type>(<type> data, <type>* ptr, > > i32 alignment, i1 host, i1 littleEndian, i1 atomic, i1 volatile, > > i1 nontemporal, i1 singlethread) FWIW here is another way to do it (which is approximately what ClamA...

...SVN and Github monorepo now. > > The following builders are already listening for changes in monorepo and building monorepo. More are coming. > > * clang-sphinx-docs > * clang-tools-sphinx-docs > * clang-x86_64-linux-abi-test > * clang-lld-x86_64-2stage > * libcxx-libcxxabi-singlethreaded-x86_64-linux-debian > * libcxx-sphinx-docs > * libunwind-sphinx-docs > * lld-sphinx-docs > * lld-x86_64-darwin13 > * lld-x86_64-ubuntu-fast > * lldb-sphinx-docs > * llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast > * llvm-clang-x86_64-win-fast <<-- ? > * llvm-sphinx-do...

...g-cmake-thumbv7-full-sh * clang-cmake-armv8-lld * clang-cmake-aarch64-full * clang-armv7-linux-build-cache * clang-aarch64-linux-build-cache * libcxx-libcxxabi-x86_64-linux-debian * libcxx-libcxxabi-x86_64-linux-debian-noexceptions * libcxx-libcxxabi-libunwind-x86_64-linux-debian * libcxx-libcxxabi-singlethreaded-x86_64-linux-debian * libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03 * libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11 * libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14 * libcxx-libcxxabi-x86_64-linux-ubuntu-cxx17 * libcxx-libcxxabi-x86_64-linux-ubuntu-cxx2a * libcxx-libcxxabi-x86_64-linux-ubuntu-32bit * libcx...

> On Aug 17, 2016, at 2:08 PM, Zhuravlyov, Konstantin <Konstantin.Zhuravlyov at amd.com> wrote: > > >Why not going with a metadata attachment directly and kill the "singlethread" keyword? Something like: > >Something like: > > cmpxchg i32* %addr, i32 42, i32 0 monotonic monotonic, 3, !memory.scope{!42} > > cmpxchg i32* %addr, i32 42, i32 0 monotonic monotonic, 3, !memory.scope{!43} > > >... > > >!42 = !{"singlethread&quot...

...Subject: Re: [llvm-dev] Memory scope proposal + Brian and Konstantin On Wed, May 18, 2016 at 11:18:53AM +0300, Pekka Jääskeläinen wrote: > Hi all, > > On 02.05.2016 17:46, Tom Stellard via llvm-dev wrote: > >>Why not going with a metadata attachment directly and kill the "singlethread" keyword? Something like: > >>>Something like: > >>> > >>> cmpxchg i32* %addr, i32 42, i32 0 monotonic monotonic, 3, > >>> !memory.scope{!42} cmpxchg i32* %addr, i32 42, i32 0 monotonic > >>> monotonic, 3, !memory.scope{!43} >...