search for: sahasrabuddh

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

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

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

...to optimize the encoding around cross thread being the most common. I'm not really a bitcode expert, so I'd rather defer to someone who has hacked on this part of LLVM more recently there. I can try to take a look at the higher level patches soon though. On Fri, Dec 12, 2014 at 10:25 AM, Sahasrabuddhe, Sameer < sameer.sahasrabuddhe at amd.com> wrote: > > On 12/11/2014 4:28 PM, Sahasrabuddhe, Sameer wrote: > > > 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...

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

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

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 Developers Mailing List > Subject: Re: [LLVMdev] SCEV bottom value > > On Sun, 7 Oct 2012 18:53:59 -0700 > Preston Briggs <preston.briggs at gmail.com> wrote: > > > I'd l...

> 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. > > I think this should be an arbitrary bit wi...

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

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 1/6/2015 1:01 PM, Chandler Carruth wrote: > > On Mon, Jan 5, 2015 at 10:51 PM, Owen Anderson <resistor at mac.com > <mailto:resistor at mac.com>> wrote: > > Hi Sameer, > > > On Jan 5, 2015, at 4:51 AM, Sahasrabuddhe, Sameer > <Sameer.Sahasrabuddhe at amd.com > <mailto: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 w...

...o 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, Tony > Subject: RE: [llvm-dev] Memory scope proposal > > Hi, > > I have updated the review here: > https://reviews.llvm.org/D21723 <https:...

..."safe default value" to be used when the metadata is dropped. If the "largest" scope is used as the default, then the optimizer must guarantee that the metadata is dropped from every atomic operation in the whole program, or not dropped at all. Thanks, Konstantin From: Sameer Sahasrabuddhe [mailto:sameer at sbuddhe.net] Sent: Sunday, July 10, 2016 4:06 AM To: Philip Reames <listmail at philipreames.com> Cc: Mehdi Amini <mehdi.amini at apple.com>; Liu, Yaxun (Sam) <Yaxun.Liu at amd.com>; Ke Bai <kebai613 at gmail.com>; Mekhanoshin, Stanislav <Stanislav.Mekh...

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

On Sat, Apr 02, 2005 at 11:35:30AM -0600, Chris Lattner wrote: > On Sat, 2 Apr 2005, Sameer D. Sahasrabuddhe wrote: > > I want to create a simple map from a Value to the instruction that > > defines it. Such a map is present inside SchedGraph, but I need it in > > a much simpler context. > > Is this in the context of the code generator? No ... I am just trying to feel the waters...

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

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