similar to: [GSoC 2016] Proposal: CFL-AA by default

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 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 devs, My GSoC project this year is about alias analysis, and I wrote a short article describing what I've done during the summer: https://github.com/grievejia/GSoC2016/raw/master/writeup.pdf In the report you can find an overview of what the current status of CFL-AA. There are also some numbers in the end, but please take those numbers with a grain of salt as they were rather

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

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

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

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

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

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

Dear LLVM Community, This is a brief summary of what I've done so far for CFL-AA, and what I plan to do next. tl;dr: CFL-AA is getting saner. Low-hanging fruits on its improvement have almost been picked up. I can either make CFL-AA more precise (with certain performance cost), or teach other passes to capitalize on CFL-AA better as the next step. Comments and suggestions are more than

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,

Wow, that is cool! I'll check about it. Thank you! On 4 March 2015 at 21:57, John Criswell <jtcriswel at gmail.com> wrote: > On 3/4/15 2:18 AM, Mingxing Zhang wrote: > > Hello John, > > Thank you for your advices and congratulations~ > > I'll read the code of cfl-aa and Giri first and make the decision of which > project to pursue. > The choice will be

Hello Daniel, Thank you for your comments and sorry for my mistakes, I'll revise them. And I'll for sure read the paper you mentioned and survey the recent researches before deciding the implementation technique. To George: May I know the exact plan of your attempt for making cfl-aa interprocedural? I do think that this is the most valuable part of my proposal, but that makes no sense to

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

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 3/8/15 8:56 AM, Mingxing Zhang wrote: > Hello John, > > According to the FAQ, I can submit two proposals although at most one > of them can be accepted. > Thus I will prepare a proposal for each of the two projects. Correct. Only one proposal will be accepted. > And, after reading the code of cfl-aa and several related papers, I've > listed four milestones for the

Hello John, Thank you for your advices and congratulations~ I'll read the code of cfl-aa and Giri first and make the decision of which project to pursue. The choice will be reported to this thread once I made the determination (hopefully within this week). Thanks! On 3 March 2015 at 23:12, John Criswell <jtcriswel at gmail.com> wrote: > Dear Mingxing, > > I think both