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

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>

> 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

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.

On Wed, May 11, 2016 at 3:02 PM, Jia Chen via llvm-dev <
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 Austinjchen at cs.utexas.edu
>
>
> _______________________________________________
> 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/cbea232f/attachment.html>

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>