search for: singlethreaded

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

> 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

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

Ke, I'll be the bearer of bad news here. The radio silence this proposal has gotten probably means there is not enough interest in the community in this proposal to see it land. One concern I have with the current proposal is that the optimization value of these scopes is not clear to me. Is it only the backend which is expected to support optimizations over these scopes? Or are you

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

> 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 1/7/2015 9:42 AM, Chandler Carruth wrote: > I think it is significantly more friendly (and easier to debug > mistakes) if the textual IR uses human readable names. We already have > a hard time due to the totally opaque nature of address spaces -- > there are magical address spaces for segment stuff in x86. > > The strings are only opaque to the target-independent

Hi all, Attached is a sequence of patches that changes the IR to support more than two synchronization scopes. This is still a work in progress, and these patches are only meant to start a more detailed discussion on the way forward. One big issue is the absence of any backend that actually makes use of intermediate synchronization scopes. This work is meant to be just one part of the

One of the projects I am working on with others is to make LLVM-IR endian agnostic. So, I am sending out this proposal for feedback to the LLVM community. I've attached pretty version of the proposal in PDF format and pasted a 80-column safe text version below. I'm looking forward to comments and feedback. Thanks, Micah Villmow Text of Proposal:

Hi all, The C++11 (& C11) compare_exchange functions with explicit memory order allow you to specify two sets of semantics, one for when the exchange actually happens and one for when it fails. Unfortunately, at the moment the LLVM IR "cmpxchg" instruction only has one ordering, which means we get sub-optimal codegen. This probably affects all architectures which use

I've not had a good chance to look at the patches in detail, but just to clarify one point: I don't really care whether we number things going up or down from single threaded to "every thread". I just think it makes sense to expose them in the in-memory IR interface as an enum with a particular ordering so that code can use the obvious sorts of tests for comparing two orderings

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

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,

Hi Micah, I'm no core developer, but FWIW here are my thoughts: I'm general I think the patch is too OpenCL oriented, and I have some niggling qualms about other parts. Specifically (comments inline): From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Villmow, Micah Sent: 03 October 2011 19:37 To: llvmdev at cs.uiuc.edu Subject:

On 1/9/2015 4:14 AM, Chandler Carruth wrote: > On Wed, Jan 7, 2015 at 8:03 PM, Sahasrabuddhe, Sameer > <sameer.sahasrabuddhe 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

On 10/03/2011 09:36 PM, Villmow, Micah wrote: > One of the projects I am working on with others is to make LLVM-IR endian agnostic. > > > > So, I am sending out this proposal for feedback to the LLVM community. I’ve attached > > pretty version of the proposal in PDF format and pasted a 80-column safe text version > > below. > > > > A second smaller

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

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

> 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

We believe that it would be best that this is added to the LLVM IR atomic memory instruction as fields on atomic instructions rather than using meta data. The reasoning is that this information is similar to other information that is represented as instruction fields. For example, the indication that memory operations are atomic rather than non-atomic, the memory ordering of atomics, and whether