[llvm-dev] Existing studies on the benefits of pointer analysis

Tue Mar 22 14:46:34 PDT 2016

----- Original Message -----
> From: "Jia Chen via llvm-dev" <llvm-dev at lists.llvm.org>
> To: "Philip Reames" <listmail at philipreames.com>, dberlin at dberlin.org
> Cc: "llvm-dev" <llvm-dev at lists.llvm.org>
> Sent: Tuesday, March 22, 2016 4:33:34 PM
> Subject: Re: [llvm-dev] Existing studies on the benefits of pointer analysis
> 
> 
> It's something that I am certainly interested in and qualified to do.
> 
> However, the way I read Daniel's reply in this thread is: "LLVM, in
> its current form, is unlikely to benefit from a more precise aa". He
> did mention that cfl-aa is "more understandable and maintainable",
> and is "fast enough", but nothing is said about the benefits. There
> was some discussions I could find back in 2014, which basically says
> that cfl-aa offers no significant improvement in performance. Things
> may got greatly improved since then, yet it is not clear to me what
> the current situation is.
> 
> With the benefits being unclear a GSoC proposal on this topic may not
> look motivated enough.
> 

I think there's wide interest in getting CFL-AA into a usable state. As I recall, the percentage of noalias results during self hosting went up by a huge amount (for example). More noalias results obviously does not guarantee better code performance (the performance could even be worse because of register allocation / scheduling deficiencies). Nevertheless, we'll never do better if we're hamstrung by poor aliasing results. 

Moreover, we currently rely heavily on BasicAA, which is a huge collection of local heuristics that catches many things, but is quite slow. It is slow because it needs to do local recursive walks for each pointwise query. If getting CFL-AA, in addition to increasing precision, provides us with a path away from our current BasicAA design toward something with better complexity, that's a definite win.

 -Hal

> 
> On 03/22/2016 01:55 PM, Philip Reames wrote:
> 
> 
> It's found more and more like "get CFL-AA turned on by default" might
> be a viable GSoC project for the right student. It would require
> someone with existing knowledge of AA and a willingness to debug
> nasty problems, but it sounds like there's definitely interest in
> the community in seeing this happen.
> 
> If the student finished early (unlikely), they could start on SCEV-AA
> as well.
> 
> Philip
> 
> 
> On 03/21/2016 01:10 PM, George Burgess IV via llvm-dev wrote:
> 
> 
> 
> 
> As of late-August 2015, putting CFL-AA behind BasicAA caused
> miscompiles when trying to bootstrap Clang/LLVM, yeah. It didn't
> seem that there were many new errors (I think it caused ~10 tests to
> fail, where fail = either segv or produce the wrong output), but it
> did end up breaking things. I don't recall if standalone CFL-AA
> causes miscompiles, but I highly doubt the breakages I observed were
> BasicAA's fault.
> 
> 
> WRT speed, `time make -j14` on my box (6c/12t) didn't show a
> meaningful increase in compile time when CFL-AA gets enabled (read:
> it got lost in the noise). So, I agree that it's probably fast
> enough at the moment; if we want to enhance it, we should focus on
> making it bootstrap clang+LLVM/making it more accurate.
> 
> 
> On Mon, Mar 21, 2016 at 12:26 PM, Hal Finkel < hfinkel at anl.gov >
> wrote:
> 
> 
> 
> 
> 
> 
> 
> 
> From: "Daniel Berlin via llvm-dev" < llvm-dev at lists.llvm.org >
> To: "Renato Golin" < renato.golin at linaro.org >, "George Burgess IV" <
> george.burgess.iv at gmail.com >
> Cc: "llvm-dev" < llvm-dev at lists.llvm.org >, "Jia Chen" <
> jchen at cs.utexas.edu >
> Sent: Monday, March 21, 2016 2:07:44 PM
> Subject: Re: [llvm-dev] Existing studies on the benefits of pointer
> analysis
> 
> 
> 
> 
> 
> 
> On Mon, Mar 21, 2016 at 12:05 PM, Renato Golin <
> renato.golin at linaro.org > wrote:
> 
> 
> On 21 March 2016 at 18:59, Daniel Berlin < dberlin at dberlin.org >
> wrote:
> > Which is why i've never mentioned it or used it in the community ;)
> 
> Makes sense. :)
> 
> 
> > I would rather see someone spend their time getting SCEV-AA on by
> > default or
> > CFL-AA on by default than doing another evaluation.
> 
> But those may not be simple enough for a GSOC, that's why I mentioned
> it.
> 
> 
> 
> 
> CFL-AA should just be fixing performance regressions, and maybe a
> little bug fixing, which is hopefully easy enough. It's already fast
> enough as a pass.
> My understanding from George is that there are self-hosting
> miscompiles if you disable all AA except for CFL-AA. This is what is
> preventing us from enabling it by default. George, is that right?
> 
> -Hal
> 
> 
> 
> 
> 
> 
> 
> 
> SCEV-AA would be harder (must make SCEV-AA faster).
> 
> 
> 
> The analysis could not only get us a birds view of the problem ahead,
> but also introduce new developers to AA, which would make their
> future
> work on SCEV-AA or CFL-AA easier. Kind of a teaching tool to get more
> AA-savvy people.
> 
> 
> 
> Sure.
> 
> 
> cheers,
> --renato
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
> 
> 
> --
> 
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> 
> 
> 
> _______________________________________________
> LLVM Developers mailing list llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> --
> Best Regards,
> 
> --
> Jia Chen
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory