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

Jia Chen via llvm-dev llvm-dev at lists.llvm.org
Wed May 11 15:02:28 PDT 2016


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160511/4dd6b6ef/attachment-0001.html>


More information about the llvm-dev mailing list