similar to: [LLVMdev] trouble with cmake+ninja

"Sahasrabuddhe, Sameer" <Sameer.Sahasrabuddhe at amd.com> writes: > I was trying Ninja to build the LLVM sources. I am using cmake version > 2.8.8, latest ninja from git and latest LLVM from git. As cmake and ninja development is not coordinated, it is not a good idea to mix versions of them separated by several months. Nor is a good idea to use a development version of

> -----Original Message----- > From: Jun Koi [mailto:junkoi2004 at gmail.com] > Sent: Thursday, October 18, 2012 8:23 PM > > > > $ cmake -DLLVM_DIR=/usr/share/llvm/cmake . > > > > This worked with both 2.8.3 and 2.8.9 > > perhaps that works for older LLVM, but not for 3.1. Actually I am using the tip of the trunk and not a release. But I think it does not

On Thu, Oct 18, 2012 at 7:22 PM, Sameer Sahasrabuddhe <sameer.sahasrabuddhe at amd.com> wrote: > On Fri, 5 Oct 2012 13:04:46 +0530 > Jun Koi <junkoi2004 at gmail.com> wrote: > >> i am wondering if this link is still updated? >> >> http://www.llvm.org/docs/CMake.html#developing-llvm-pass-out-of-source >> >> i follow the instruction from the link,

On Tue, Jan 13, 2015 at 10:27 PM, Sameer Sahasrabuddhe < sameer.sahasrabuddhe at amd.com> wrote: > Ping! We need to close on whether everyone is convinced that symbolic > memory scopes have a significant advantage over opaque numbers. Either of > them will be examined by optimizations using a target-implemented API. I > personally don't think that readability in the LLVM

On Fri, 5 Oct 2012 13:04:46 +0530 Jun Koi <junkoi2004 at gmail.com> wrote: > i am wondering if this link is still updated? > > http://www.llvm.org/docs/CMake.html#developing-llvm-pass-out-of-source > > i follow the instruction from the link, and create in my ~/test/ > directory the CMakeLists.txt with following content: > <snip> > CMake Warning at

hi, i am wondering if this link is still updated? http://www.llvm.org/docs/CMake.html#developing-llvm-pass-out-of-source i follow the instruction from the link, and create in my ~/test/ directory the CMakeLists.txt with following content: $cat test/CMakeLists.txt find_package(LLVM) # Define add_llvm_* macro's. include(AddLLVM) add_definitions(${LLVM_DEFINITIONS})

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 11/15/2014 12:08 AM, Tom Stellard wrote: > Can you send a plain-text version of this email. It's easier to read > and reply to. Sorry about that! Here's the plain text (I hope!): Hi all, OpenCL 2.0 introduced 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

Hi, git messages for the LLVM source quote the equivalent SVN revisions with a line like this: git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 165785 91177308-0d34-0410-b5e6-96231b3b80d8 But the URL doesn't work; instead we get the following error message: The requested URL /svn/llvm-project/llvm/trunk at 165785 was not found on this server. The tip of the trunk is visible

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 Preston, I was wondering ... "Bottom" is a bit overloaded as far as terms go. Would SCEVNaN be a better name for this beast? Sameer. > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of Sameer Sahasrabuddhe > Sent: Monday, October 08, 2012 9:16 AM > To: preston.briggs at gmail.com > Cc: LLVM

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

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

> 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

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

On Sun, 7 Oct 2012 18:53:59 -0700 Preston Briggs <preston.briggs at gmail.com> wrote: > I'd like a value, call it Bottom, such that > > SE->getAddExpr(Bottom, X) => Bottom > SE->getMulExpr(Bottom, X,) => Bottom > isKnownPredicate(any, Bottom, X) => false > etc. > > > I can write code to make NULL work like I want, but it would be > simpler

I'd like a value, call it Bottom, such that SE->getAddExpr(Bottom, X) => Bottom SE->getMulExpr(Bottom, X,) => Bottom isKnownPredicate(any, Bottom, X) => false etc. I can write code to make NULL work like I want, but it would be simpler if something was already defined. I'm wondering about SCEV::Unknown. The documentation suggests I could perhaps use it for a

Hi, The docs available on illuvium.com are different from the one's present in the doxygen tarball on the same page ... can the tarball be generated from the same docs as the browseable version? I considered crawling the illuvium.com site, but it would be better to simply have a tarball available. I tried generating the docs myself ... doxygen simply refuses to create pages for classes

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