search for: cflaa

Hi David, I am the one who's responsible for CFLAA's refactoring in the summer. I've sent out another email on llvm-dev, and you can find more about my work in my GSoC final report. I think it is fantastic that you have done such an interesting work. I'll definitely try to help getting the code reviewed and merged in the current. A...

...ant 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 analysis and it appears the prior CFLAA has been abandoned. There was quite a bit of refactoring done, yeah. The original CFLAA is now called CFLSteens, and graph construction was moved to its own bit. We also have CFLAnders, which is based more h...

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

So, I split it up into three patches: - cflaa-danny-fixes.diff are (some of?) the fixes that Danny gave us earlier for tests + the minimal modifications you’d need to make in CFLAA to make them pass tests. - cflaa-minor-bugfixes.diff consists primarily of a bug fix for Argument handling — we’d always report NoAlias when one of the given varia...

...> > George, given that, can you just build constexpr handling (it's not > > as easy as you think) as a separate funciton and have it use it in > > the right places? > > Will do. :) > > > > > > > > > > > > FWIW, my current list of CFLAA issues is: > > > > 1. Unknown values (results from ptrtoint, incoming pointers, etc) > > are > > not treated as unknown. These should be done through graph edge (so > > that they can be one way, otherwise, you will unify everything :P) > > > > > >...

...Daniel Berlin" <dberlin at dberlin.org> > > Sent: Friday, January 30, 2015 10:34:43 PM > > Subject: Re: [LLVMdev] question about enabling cfl-aa and collecting a57 > numbers > > > > > > So, I split it up into three patches: > > > > > > - cflaa-danny-fixes.diff are (some of?) the fixes that Danny gave us > > earlier for tests + the minimal modifications you’d need to make in > > CFLAA to make them pass tests. > > - cflaa-minor-bugfixes.diff consists primarily of a bug fix for > > Argument handling — we’d always rep...

...Callahan <dcallahan at fb.com<mailto:dcallahan at fb.com>> Cc: George Burgess IV <george.burgess.iv at gmail.com<mailto:george.burgess.iv at gmail.com>>, LLVM Dev Mailing list <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> Subject: Re: [llvm-dev] CFLAA Hey David, I'll take a look at the patch :) Sounds like fun work. As George says, improving AA significantly will almost always cause significant performance regressions at first, in almost any compiler. Compilers knobs, passes, usually get tuned for x amount of freedom, and if you give the...

...in at dberlin.org> >> Date: Thursday, August 25, 2016 at 9:06 AM >> To: David Callahan <dcallahan at fb.com> >> Cc: George Burgess IV <george.burgess.iv at gmail.com>, LLVM Dev Mailing >> list <llvm-dev at lists.llvm.org> >> Subject: Re: [llvm-dev] CFLAA >> >> Hey David, >> I'll take a look at the patch :) >> Sounds like fun work. >> >> As George says, improving AA significantly will almost always cause >> significant performance regressions at first, in almost any compiler. >> >> Compilers...

...> > > George, given that, can you just build constexpr handling (it's not > > as easy as you think) as a separate funciton and have it use it in > > the right places? > > Will do. :) > > > > > > > > > > > > FWIW, my current list of CFLAA issues is: > > > > 1. Unknown values (results from ptrtoint, incoming pointers, etc) are > > not treated as unknown. These should be done through graph edge (so > > that they can be one way, otherwise, you will unify everything :P) > > > > > > > > &gt...

George, given that, can you just build constexpr handling (it's not as easy as you think) as a separate funciton and have it use it in the right places? FWIW, my current list of CFLAA issues is: 1. Unknown values (results from ptrtoint, incoming pointers, etc) are not treated as unknown. These should be done through graph edge (so that they can be one way, otherwise, you will unify everything :P) 2. Constexpr handling ^^^ These are correctness issues. I'm pretty sure ther...

I'm pretty sure I had the ordering of the passes backwards. The previous ordering is correct. Sorry for the confusion. The last alias analysis created is the first one queried. It delegates to the previous alias analysis created. At least, that is my reading of this (very confusing) code. The most frustrating aspect of this is that it means the delegation behavior of CFL shouldn't have

...e > On Jan 26, 2015, at 1:05 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > George, given that, can you just build constexpr handling (it's not as easy as you think) as a separate funciton and have it use it in the right places? Will do. :) > FWIW, my current list of CFLAA issues is: > > 1. Unknown values (results from ptrtoint, incoming pointers, etc) are not treated as unknown. These should be done through graph edge (so that they can be one way, otherwise, you will unify everything :P) > 2. Constexpr handling > ^^^ These are correctness issues. I'...

..., at 1:05 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > > George, given that, can you just build constexpr handling (it's not as > easy as you think) as a separate funciton and have it use it in the right > places? > > Will do. :) > > FWIW, my current list of CFLAA issues is: > > 1. Unknown values (results from ptrtoint, incoming pointers, etc) are not > treated as unknown. These should be done through graph edge (so that they > can be one way, otherwise, you will unify everything :P) > > 2. Constexpr handling > > ^^^ These are correc...

On 13 January 2015 at 22:11, Daniel Berlin <dberlin at dberlin.org> wrote: > This is caused by CFLAA returning PartialAlias for a query that BasicAA > can prove is NoAlias. > One of them is wrong. Which one? I'm not sure from your description that this is a chaining issue. PartialAlias doesn't chain and isn't supposed to, it's a final answer just like NoAlias and MustAlias...

...inal Message ----- > From: "George Burgess IV" <george.burgess.iv at gmail.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Sent: Friday, January 30, 2015 10:54:17 AM > Subject: BasicAA Tests > > > Hey, > > > As I was going through the CFLAA tests, I noticed that some of them > were passing when they shouldn't have. This was due to that they had > ; CHECK-NOT: May: > > > Which doesn't match up with the output of -print-may-alias: > MayAlias: %Type %A, %Type2 %B > > > ...So they'd always pass &...

dear LLVMers, I am trying to use some of the LLVM alias analyses, and I would like to check two things with you: is scev-aa being maintained in LLVM 3.7? Second question: I run cfl-aa, and I got a very small number of pointer disambiguation (no alias) with it. My results for SPEC CINT 2006 follow below. Is this low number of no alias responses something to be excepted? Below the results that I

...10:49 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > >> On Tue, Jan 13, 2015 at 11:26 PM, Nick Lewycky <nlewycky at google.com> wrote: >>> On 13 January 2015 at 22:11, Daniel Berlin <dberlin at dberlin.org> wrote: >>> This is caused by CFLAA returning PartialAlias for a query that BasicAA can prove is NoAlias. >> >> One of them is wrong. Which one? > CFL-AA. > > Right now it checks whether two things come out to be the same stratified info and have the same index, and if so, returns PartialAlias. This is wrong,...

...isting to while.body.lr.ph: %arrayidx81 = getelementptr >> inbounds double* %11, i64 2 >> LICM hoisting to for.body.lr.ph: %2 = ptrtoint i32* %Index to i64 >> >> clang --target=aarch64-linux-gnu -c -mcpu=cortex-a57 -Ofast >> -fno-math-errno test.c -S -o test-cflaa.s -mllvm -use-cfl-aa -mllvm >> -debug-only=licm >> LICM hoisting to for.body.lr.ph: %2 = ptrtoint i32* %Index to i64 >> >> Why CFL AA cannot allow hoisting this out: %21 = load double** >> %arrayidx8, align 8, !tbaa !5 >> >> Which leads to this extra loa...

...een studying LLVM code sections related to SSA construction, dominance frontiers,etc. I also made some contributions to the Polly project. Currently I am interested in improving the existing alias analysis infrastructure as part of my GSoC-15 project. The current pointer analyses in LLVM (basicaa, cflaa etc.) compute imprecise information as none of them are flow-sensitive. The aim of my project is to implement a pass that computes more precise points-to pairs that is both flow-sensitive as well as context-sensitive. This method has been described in  Liveness-Based Pointer Analysis [http://www.cs...

...0:49 AM, Daniel Berlin <dberlin at dberlin.org> wrote: > > > > > > On Tue, Jan 13, 2015 at 11:26 PM, Nick Lewycky <nlewycky at google.com> > wrote: > > On 13 January 2015 at 22:11, Daniel Berlin <dberlin at dberlin.org> wrote: > > This is caused by CFLAA returning PartialAlias for a query that BasicAA > can prove is NoAlias. > > > > One of them is wrong. Which one? > > > > CFL-AA. > > > > Right now it checks whether two things come out to be the same stratified > info and have the same index, and if so, ret...