[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