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

Jia Chen via llvm-dev llvm-dev at lists.llvm.org
Fri May 13 07:02:56 PDT 2016


Hi Dibyendu,

All I have at this point is llvm test-suite. I also have access to 
SPEC'06, which may be helpful as well. My hope is that the applications 
in those benchmarks are complex enough to put enough pressure on cfl-aa.

That being said, I'm not an expert in performance testing, and I am open 
to suggestions on this topic.

On 05/12/2016 11:53 PM, Das, Dibyendu wrote:
>
> 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
>

-- 
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/20160513/84074d32/attachment.html>


More information about the llvm-dev mailing list