similar to: [GSoC] Final project report on CFL-AA

dear LLVMers, I am trying to use some of the LLVM alias analyses, and I would like to check two things with you: is scev-aa being maintained in LLVM 3.7? Second question: I run cfl-aa, and I got a very small number of pointer disambiguation (no alias) with it. My results for SPEC CINT 2006 follow below. Is this low number of no alias responses something to be excepted? Below the results that I

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

Hi, I'm looking for interprocedural AAs and have, of course, found https://llvm.org/docs/AliasAnalysis.html. However, the AAs that come bundled with LLVM do not work interprocedurally in a way that I need it (on/with stack variables). The two interesting looking AAs come with the optional `poolalloc' module that hasn't been updated in years (I guess

Oops thanks for the reminder. I did use another email address and am terribly sorry for it. Let me just post the link: https://docs.google.com/document/d/1Kvepb-v5Ta8ug_lLK1kZeexPNlpvj62K5iIF0fMuLyM/edit?usp=sharing On 03/25/2016 11:44 AM, John Criswell wrote: > Dear Jia, > > I don't see your proposal in the system. What is the title of your > proposal, and under what email

Dear llvm devs, Based on an earlier discussion about existing pointer analyses in LLVM, I quickly hacked up a GSoC proposal on enabling cfl-aa by default. The decision to write it was made two days before the application deadline, hence the writing quality may not be very satisfactory: the background section could be less verbose, and the implementation section could be more formal. Also it

Hi Geoff, Thank you so much for the effort! It's good to hear that cfl-aa didn't break anything. However, the fact that it doesn't quite affect code generation is also concerning. I'll definitely look into the issue. On 05/19/2016 02:03 PM, Geoff Berry wrote: > Hi Jia, > > We did some testing with CFL-AA enabled on an aarch64 OoO target on the > llvm test-suite and

Hello everyone, If you've read through my previous introduction email (http://lists.llvm.org/pipermail/llvm-dev/2016-May/099573.html), you can safely ignore this message. The short story is: CFL-AA does not seem to be broken anymore. Please try it out and help us find more bugs / performance issues if switching to it in the future sounds interesting to you. Here are more backgrounds: I

Dear Jia, I don't see your proposal in the system. What is the title of your proposal, and under what email address did you submit it? Regards, John Criswell On 3/23/16 4:09 PM, Jia Chen via llvm-dev wrote: > Dear llvm devs, > > Based on an earlier discussion about existing pointer analyses in > LLVM, I quickly hacked up a GSoC proposal on enabling cfl-aa by default. >

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,

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

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

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

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

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 05/11/2016 05:16 PM, George Burgess IV via llvm-dev wrote: > > After applying the patch on r267335 and bootstrap LLVM/clang with > cfl-aa enabled on its own as well as behind basic-aa on an x86 > machine, I ran test-suite with lit and saw no failed test cases > > Woohoo! This is great news. :D Awesome! > > I'm not sure how closely everyone is reading the intro

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

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