similar to: Existing studies on the benefits of pointer analysis

Hi Christian, Thank you so much for the reply! Please see my comments inline. On 03/21/2016 09:32 AM, Christian Convey wrote: > Hi Jia, > > If one looks at existing research literatures, there are even more > algorithm to consider for doing pointer analysis. > > > For at least some published AA algorithms, there may be some > uncertainty about software patents

Hi Daniel, On 03/21/2016 11:05 AM, Daniel Berlin wrote: > > > On Tue, Mar 15, 2016 at 1:37 PM, Jia Chen via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Dear llvm devs, > > tl;dr: What prevents llvm from switching to a fancier pointer > analysis? > > > Nothing. > > > Currently,

> It is merely a demand-driven way of implementing existing > analyses, by extending those algorithms to track additional > "pointed-to-by" information. Laziness may help with the running > time of the cfl analysis when only partial points-to info is > needed, but if the client wants to do a whole-program analysis and > require whole-program

> You can solve andersens and steengaards and everything else using > standard dataflow solvers, and that's an implementation strategy, but > it will be really slow. > > Part of the tradeoff is how fast something runs, and approaches that > are orders of magnitude faster often change the calculus of what > people do. For example, before hardekopf's work, andersens

On Mon, Mar 21, 2016 at 6:28 PM, Philip Reames via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On 03/21/2016 08:56 AM, Jia Chen via llvm-dev wrote: > > Hi Christian, > > Thank you so much for the reply! Please see my comments inline. > > On 03/21/2016 09:32 AM, Christian Convey wrote: > > Hi Jia, > > If one looks at existing research

On Mar 21, 2016, at 10:00 AM, Jia Chen via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> So my question here is: what kind(s) of precision really justify the cost and what kinds do not? >> >> Depends entirely on your applications. >> >> Has anybody done any study in the past to evaluate what kinds of features in pointer analyses will benefit what

Hi David, I am the one who's responsible for CFLAA's refactoring in the summer. I've sent out another email on llvm-dev, and you can find more about my work in my GSoC final report. I think it is fantastic that you have done such an interesting work. I'll definitely try to help getting the code reviewed and merged in the current. After a quick glance at your patch, it seems

On 21 March 2016 at 17:17, Daniel Berlin via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> Has anybody done any study in the past to evaluate what kinds of features >>> in pointer analyses will benefit what kinds of optimization passes? >> >> Yes. >> Chris did many years ago, and i've done one more recently. >> >> Great! Are they

> > > > I’m still a big fan of context sensitive, flow insensitive, unification > based models. > CFL can emulate this in the same time bound. > Contrary to your claim, context sensitivity *is* useful for mod-ref > analysis, e.g. “can I hoist a load across this call”? Context sensitivity > improves the precision of the mod/ref set of the call. > > -Chris >

On 21 March 2016 at 18:59, Daniel Berlin <dberlin at dberlin.org> wrote: > Which is why i've never mentioned it or used it in the community ;) Makes sense. :) > I would rather see someone spend their time getting SCEV-AA on by default or > CFL-AA on by default than doing another evaluation. But those may not be simple enough for a GSOC, that's why I mentioned it. The

----- Original Message ----- > From: "Daniel Berlin via llvm-dev" <llvm-dev at lists.llvm.org> > To: "Renato Golin" <renato.golin at linaro.org>, "George Burgess IV" > <george.burgess.iv at gmail.com> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Jia Chen" > <jchen at cs.utexas.edu> > Sent: Monday,

It's something that I am certainly interested in and qualified to do. However, the way I read Daniel's reply in this thread is: "LLVM, in its current form, is unlikely to benefit from a more precise aa". He did mention that cfl-aa is "more understandable and maintainable", and is "fast enough", but nothing is said about the benefits. There was some

On 03/25/2016 08:08 PM, Chris Lattner wrote: > I’m still a big fan of context sensitive, flow insensitive, > unification based models. Interestingly I find the unification approach quite unsatisfactory sometime. What happens there is pointers with the same "depth" are too often clobbered together unless they are really unrelated to each other. > Contrary to your claim,

As of late-August 2015, putting CFL-AA behind BasicAA caused miscompiles when trying to bootstrap Clang/LLVM, yeah. It didn't seem that there were many new errors (I think it caused ~10 tests to fail, where fail = either segv or produce the wrong output), but it did end up breaking things. I don't recall if standalone CFL-AA causes miscompiles, but I highly doubt the breakages I observed

On 03/28/2016 12:37 AM, Chris Lattner wrote: > It changes all the time. Here’s a trivial example, assume no inlining > and no AA other than the one in question: > > std::vector<int> V1 = { 1, 2, 3 }; > std::vector<int> V2 = { 4, 5, 6 }; > > V1.pop_back(); // Mutates *this > > auto length = V1.size(); > > V2.pop_back(); //

It's found more and more like "get CFL-AA turned on by default" might be a viable GSoC project for the right student. It would require someone with existing knowledge of AA and a willingness to debug nasty problems, but it sounds like there's definitely interest in the community in seeing this happen. If the student finished early (unlikely), they could start on SCEV-AA as

On 03/25/2016 08:26 PM, Daniel Berlin wrote: > > Yeah. > It depends entirely on your goal. In reality, often what you really > want is something to say "hey, i've got this pointer over here, and i > really want to hoist it up here. Do something, tell me if that is > possible". > And this is one motivation of my current research: how can various precision

> On Mar 25, 2016, at 9:04 PM, Jia Chen <jchen at cs.utexas.edu> wrote: > > On 03/25/2016 08:08 PM, Chris Lattner wrote: >> I’m still a big fan of context sensitive, flow insensitive, unification based models. > > Interestingly I find the unification approach quite unsatisfactory sometime. What happens there is pointers with the same "depth" are too often

Dear LLVM community, I am a GSoC student this year working on the project of improving alias analysis in LLVM. The proposal initially came from a discussion I had with various devs on the mailing list some time ago [1]. The general goal of this project is to make alias analysis (in particular, cfl-aa) "better", and to be more concrete here is a list of objectives I had in mind: -

(Just to note: the other issue i remember with CFL-AA is that it currently causes performance loss. This is quite common when you increase precision, because things move/change things they couldn't before, and often do so without the natural bounds imprecision provided before :P) On Thu, May 12, 2016 at 12:29 AM, James Molloy via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Yep,