[llvm-dev] [GSoC 2016] Introduction & Feedback - Better Alias Analysis
Philip Reames via llvm-dev
llvm-dev at lists.llvm.org
Wed May 11 21:57:41 PDT 2016
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
> 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/20160511/1b68220e/attachment.html>
More information about the llvm-dev
mailing list