search for: pointermaybecaptur

Hello Anna, I've been looking into compiling a list of all of the false positives in the current Capture Tracking Analysis, but I'm having a bit of trouble getting my head around it all. I feel like I understand it at a theoretical level but jumping into the implementation is quite daunting. I would appreciate any advice you could give to point me in the right direction. Many thanks,

...cache itself, and we're building it with a stateless tool. We know that while building MemorySSA, there are no changes in the program, and yet, there is info that is computed again and again. One example is this patch: D57627 <https://reviews.llvm.org/D57627>. The patch adds a cache for PointerMayBeCaptured, which is cleared after every alias() call, in order to keep BasicAA stateless. In the example given in the patch, not clearing the isCapturedCache reduces compile times by another second. In some pathological cases I'm looking at, not-clearing this cache halves compile times (from 8s to 4s)....

...clang put in a bunch of bitcasts and stuck the vtbl itself into an array; ripping all that out made no difference) Tracing through MemoryDependenceAnalysis and BasicAA, it turns out that the store into %ppVtbl (a pointer to the instance's vtbl pointer) is clobbered by the call to @puts because PointerMayBeCaptured gets called on it when the @puts call is encountered and returns true because %pinstance is passed through %pVfn1 to make the virtual method call, and the call to %pVfn1 (unlike the actual function that %pVfn1 must point to) does not declare the 'this' parameter nocapture. The devirtuali...

...ent way to determine dependent > instructions than like in the code below? In particular, I'm wondering > if it is possible to find all loads that depend on a particular store > more efficiently? I don't think memory dependence analysis is appropriate for this. The function llvm::PointerMayBeCaptured in CaptureTracking.cpp does something like what you are trying to do. It used to track stores and loads from them, but this was removed because it was not helpful in practice. The way it used to track stores and loads was simple. First, it only tried to analysis stores to local variables (Allo...

PR43308 describes a case where StackProtector fails to protect against a fairly simple smash. This problem started after r363169, which removed StackProtector's own analysis function HasAddressTaken, and used CaptureTracking's PointerMayBeCaptured instead. The problem here is that "pointer is captured" and "pointer could be used to smash the stack" are not equivalent queries. The header of CaptureTracking.cpp says in part: A pointer value is captured if the function makes a copy of any part of the pointer that out...

...building it with a > stateless tool. > We know that while building MemorySSA, there are no changes in the > program, and yet, there is info that is computed again and again. > > One example is this patch: D57627 <https://reviews.llvm.org/D57627>. The > patch adds a cache for PointerMayBeCaptured, which is cleared after every > alias() call, in order to keep BasicAA stateless. In the example given in > the patch, not clearing the isCapturedCache reduces compile times by > another second. In some pathological cases I'm looking at, not-clearing > this cache halves compile ti...

...dent >> instructions than like in the code below? In particular, I'm wondering >> if it is possible to find all loads that depend on a particular store >> more efficiently? > > I don't think memory dependence analysis is appropriate for this.  The function > llvm::PointerMayBeCaptured in CaptureTracking.cpp does something like what you > are trying to do.  It used to track stores and loads from them, but this was > removed because it was not helpful in practice.  The way it used to track > stores and loads was simple.  First, it only tried to analysis stores to local...

Hello! I am trying to retrieve all instructions from a function's body that are dependent on a specific argument. The strategy I am currently using for that is to follow all uses of the argument and record them. Also, whenever I encounter a store of a dependent value, I try to find loads in the function that are dependent on that store and resume use-tracking from there. For this purpose I am

Hello, Attached is the proposal that I have submitted. I would be grateful for any and all feedback provided. Many Thanks, Scott -------------- next part -------------- A non-text attachment was scrubbed... Name: GSoc Proposal 2016 - Scott Egerton.pdf Type: application/pdf Size: 391088 bytes Desc: GSoc Proposal 2016 - Scott Egerton.pdf URL:

----- Original Message ----- > From: "James Molloy via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Vaivaswatha Nagaraj" <vn at compilertree.com> > Cc: "LLVM Dev" <llvm-dev at lists.llvm.org> > Sent: Thursday, December 3, 2015 4:41:46 AM > Subject: Re: [llvm-dev] Function attributes for LibFunc and its impact on GlobalsAA > >