[llvm-dev] [GSoC 2016] Introduction & Feedback - Better Alias Analysis

Thu May 12 21:53:00 PDT 2016

Hi Jia-

What apps/benchmarks do you plan to use to test the performance of cfl-aa ?

-Dibyendu

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of George Burgess IV via llvm-dev
Sent: Thursday, May 12, 2016 11:16 PM
To: James Molloy <james at jamesmolloy.co.uk>
Cc: llvm-dev <llvm-dev at lists.llvm.org>; Jia Chen <jchen at cs.utexas.edu>
Subject: Re: [llvm-dev] [GSoC 2016] Introduction & Feedback - Better Alias Analysis

> What's the magic rune to enable cfl-aa?

We have two magical opt flags: -use-cfl-aa and -use-cfl-aa-in-codegen :)

IIRC, both of them should cause CFLAA to be enabled as a last resort.

On Thu, May 12, 2016 at 12:38 AM, Daniel Berlin <dberlin at dberlin.org<mailto:dberlin at dberlin.org>> wrote:
(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<mailto:llvm-dev at lists.llvm.org>> wrote:
Yep, same. What's the magic rune to enable cfl-aa?

James

On Thu, 12 May 2016 at 05:58 Philip Reames via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
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 emails, so we may get more help if we also send a slightly more targeted "Hey, CFLAA isn't obviously broken anymore. Please help us find any other problems/please report performance numbers to us," email. Whether we do that this very second, or when GSoC actually starts, is up to you.
Once this lands in tree, I'll do a run on our codebase to see if I see anything obvious.  I suspect others can do the same.

Philip

On Wed, May 11, 2016 at 3:02 PM, Jia Chen via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
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:

- Evaluating the current state of cfl-aa, and fix all known bugs.
- Improving the precision of cfl-aa. Although flow sensitivity may not be very helpful for LLVM in its current form, field sensitivity should be something important and I'll definitely try to add it to cfl-aa. Given the complexity LLVM's memory model has, my guess is that I may need to spend most of my summer on this task.
- Improving the performance of cfl-aa. (It is fairly efficient in its current form, IMO. Further performance tuning may be needed if more features such as field sensitivity were added.)
- Understanding how various clients interacts with cfl-aa, and exploring various ways to minimize precision/performance losses caused by the interaction.
- If time permits, maybe I can look at scev-aa and try to bring it back to the compilation pipeline.

I know these objectives are not as clear cut as other GSoC projects people used to have, and it is hard to come up with a clear schedule as well as a success metric. Nevertheless even if my contributions may seem fragmented and incremental, I felt that as long as the work is useful to the community, it is going to be the most valuable summer I've ever had as a student.

** Current Status **

I've submitted a simple patch last week (D19776) to fix a subtle bug in cfl-aa. 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. I didn't time the tests in any rigorous way, but it didn't look like cfl-aa add very noticable performance overhead. It may be a good time, I think, to call for people's help to test cfl-aa on their internal codebase. If everything goes well, we should be able to safely turn on cfl-aa by default soon.

Let me conclude this introduction by saying thank you for accepting my proposal, and in particular I want to thank my mentors George and Hal for the providing me with so much support and guidance. Please let me know if you have any comments or suggestions.

[1] http://lists.llvm.org/pipermail/llvm-dev/2016-March/096851.html

--

Best Regards,

--

Jia Chen

Department of Computer Science

University of Texas at Austin

jchen at cs.utexas.edu<mailto:jchen at cs.utexas.edu>

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________

LLVM Developers mailing list

llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>

http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160513/0d93852b/attachment.html>