similar to: [LLVMdev] SCEV bottom value

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

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

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On > Behalf Of Hal Finkel > Sent: Monday, October 08, 2012 1:35 AM > > I'd like to add that, mostly through Tobi's efforts, we were able to have isl (the > integer set library) on which Polly depends relicensed such that it is now > distributed under the MIT

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

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

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

It would be great to get "accurate" dependence analysis from polyhedral framework. Anyone working on making polly into analysis+Transforms framework? -Prashantha -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Sahasrabuddhe, Sameer Sent: Monday, October 08, 2012 9:03 AM To: Hal Finkel; Javed Absar Cc: llvmdev at

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

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

Marco Matthies wrote: >> make[2]: Entering directory `/home/sameerds/data/llvm-1.6/tools/llc' >> llvm[2]: Linking Debug executable llc >> `.gnu.linkonce.t._ZNK4llvm14TargetLowering12getValueTypeEPKNS_4TypeE' >> referenced >> in section `.rodata' of >> /home/sameerds/data/llvm-1.6/Debug/lib/LLVMSelectionDAG >> .o: defined in discarded

Hi, 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. Here's what I tried: $ cmake -G Ninja -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=... /path/to/src $ ninja $ ninja install The installation aborted with the message below: CMake Error at utils/TableGen/cmake_install.cmake:36 (FILE): file INSTALL cannot

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,