similar to: CFLAA

(Adding "LLVM Dev") My variant is up as https://reviews.llvm.org/D23876 -david From: George Burgess IV <george.burgess.iv at gmail.com<mailto:george.burgess.iv at gmail.com>> Date: Wednesday, August 24, 2016 at 3:17 PM To: David Callahan <dcallahan at fb.com<mailto:dcallahan at fb.com>> Subject: Re: CFLAA Hi! > I see there is on going work with alias

(and sys::cas_flag that STATISTIC uses is a uint32 ...) On Thu, Aug 25, 2016 at 9:54 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > Okay, dumb question: > Are you really getting negative numbers in the second column? > > 526,766 -136 mem2reg # PHI nodes inserted > > http://llvm.org/docs/doxygen/html/PromoteMemoryToRegister_8cpp_source.html >

I did gathered aggregate statistics reported by “-stats” over the ~400 test files. The following table summarizes the impact. The first column is the sum where the new analysis is enabled, the second column is the delta from baseline where no CFL alias analysis is performed. I am not experienced enough to know which of these are “good” or “bad” indicators. —david 72,250 685 SLP

Hi Geoff, Thank you so much for the effort! It's good to hear that cfl-aa didn't break anything. However, the fact that it doesn't quite affect code generation is also concerning. I'll definitely look into the issue. On 05/19/2016 02:03 PM, Geoff Berry wrote: > Hi Jia, > > We did some testing with CFL-AA enabled on an aarch64 OoO target on the > llvm test-suite and

(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> wrote: > Yep,

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: -

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

Hi Daniel, On 03/21/2016 11:05 AM, Daniel Berlin wrote: > > > On Tue, Mar 15, 2016 at 1:37 PM, Jia Chen via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > Dear llvm devs, > > tl;dr: What prevents llvm from switching to a fancier pointer > analysis? > > > Nothing. > > > Currently,

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

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

----- Original Message ----- > 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,

Hello everyone, If you've read through my previous introduction email (http://lists.llvm.org/pipermail/llvm-dev/2016-May/099573.html), you can safely ignore this message. The short story is: CFL-AA does not seem to be broken anymore. Please try it out and help us find more bugs / performance issues if switching to it in the future sounds interesting to you. Here are more backgrounds: I

Dear LLVM devs, My GSoC project this year is about alias analysis, and I wrote a short article describing what I've done during the summer: https://github.com/grievejia/GSoC2016/raw/master/writeup.pdf In the report you can find an overview of what the current status of CFL-AA. There are also some numbers in the end, but please take those numbers with a grain of salt as they were rather

Dear llvm devs, tl;dr: What prevents llvm from switching to a fancier pointer analysis? Currently, there exists a variety of general-purpose alias analyses in the LLVM codebase: basic-aa, globalsmodref-aa, tbaa, scev-aa, and cfl-aa. However, only the first three are actually turned on when invoking clang with -O2 or -O3 (please correct me if I'm wrong about this). If one looks at

> > > > I’m still a big fan of context sensitive, flow insensitive, unification > based models. > CFL can emulate this in the same time bound. > Contrary to your claim, context sensitivity *is* useful for mod-ref > analysis, e.g. “can I hoist a load across this call”? Context sensitivity > improves the precision of the mod/ref set of the call. > > -Chris >

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

On 03/25/2016 08:26 PM, Daniel Berlin wrote: > > Yeah. > It depends entirely on your goal. In reality, often what you really > want is something to say "hey, i've got this pointer over here, and i > really want to hoist it up here. Do something, tell me if that is > possible". > And this is one motivation of my current research: how can various precision

> It is merely a demand-driven way of implementing existing > analyses, by extending those algorithms to track additional > "pointed-to-by" information. Laziness may help with the running > time of the cfl analysis when only partial points-to info is > needed, but if the client wants to do a whole-program analysis and > require whole-program

> You can solve andersens and steengaards and everything else using > standard dataflow solvers, and that's an implementation strategy, but > it will be really slow. > > Part of the tradeoff is how fast something runs, and approaches that > are orders of magnitude faster often change the calculus of what > people do. For example, before hardekopf's work, andersens

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. The