similar to: [LLVMdev] Testing the new CFL alias analysis

In lto+pgo some (5 out of 12 with usual suspect like perlbench and gcc among them using -flto -Wl,-mllvm,-use-cfl-aa -Wl,-mllvm,-use-cfl-aa-in-codegen) the CINT2006 benchmarks don’t compile. Has the implementation been tested with lto? If not, please stress the implementation more. Do we know reasons for gains? Where did you expect the biggest gains? Some of the losses will likely boil down to

On CINT2006 ARM64/ref input/lto+pgo I practically measure no performance difference for the 7 benchmarks that compile. This includes bzip2 (although different source base than in CINT2000), mcf, hmmer, sjeng, h364ref, astar, xalancbmk On Sep 15, 2014, at 11:59 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Gerolf Hoflehner"

----- Original Message ----- > From: "Gerolf Hoflehner" <ghoflehner at apple.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Dev" <llvmdev at cs.uiuc.edu>, "Jiangning Liu" <liujiangning1 at gmail.com>, "George Burgess IV" > <george.burgess.iv at gmail.com> > Sent: Monday, September 15, 2014

Hi folks, Moving the discussion to llvm.dev. None of the changes we talked earlier help. Find attached the C source code that you can use to reproduce the issue. clang --target=aarch64-linux-gnu -c -mcpu=cortex-a57 -Ofast -fno-math-errno test.c -S -o test.s -mllvm -debug-only=licm LICM hoisting to while.body.lr.ph: %21 = load double** %arrayidx8, align 8, !tbaa !5 LICM hoisting to

Can you send me actual LLVM IR or a preprocessed source from using -E? I don't have a machine handy that has headers that target that arch. On Tue Jan 13 2015 at 4:33:29 PM Daniel Berlin <dberlin at dberlin.org> wrote: > Anything other than noalias or mustalias should be getting passed down the > stack, so either that is not happening or CFL aa is giving better answers > and

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

Inline - George > On Jan 14, 2015, at 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

Oh, sorry, i didn't rebase it when i changed the fix, you would have had to apply the first on top of the second. Here is one against HEAD On Wed, Jan 14, 2015 at 12:32 PM, Ana Pazos <apazos at codeaurora.org> wrote: > Daniel, your patch does not apply cleanly. Are you on the tip? > > The code I see there is no line if (QueryResult == MayAlias|| QueryResult == PartialAlias)

Yes. I've attached an updated patch that does the following: 1. Fixes the partialalias of globals/arguments 2. Enables partialalias for cases where nothing has been unified to a global/argument 3. Fixes that select was unifying the condition to the other pieces (the condition does not need to be processed :P). This was causing unnecessary aliasing. 4. Adds a regression test to

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

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

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

Hi Danny, // Add TypeBasedAliasAnalysis before BasicAliasAnalysis so that // BasicAliasAnalysis wins if they disagree. This is intended to help // support "obvious" type-punning idioms. - if (UseCFLAA) - addPass(createCFLAliasAnalysisPass()); addPass(createTypeBasedAliasAnalysisPass()); addPass(createScopedNoAliasAAPass()); + if (UseCFLAA) +

----- Original Message ----- > From: "Daniel Berlin" <dberlin at dberlin.org> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Jiangning Liu" <Jiangning.Liu at arm.com>, "George Burgess IV" <george.burgess.iv at gmail.com>, "LLVM Developers > Mailing List" <llvmdev at cs.uiuc.edu>, "Nick Lewycky"

Oops thanks for the reminder. I did use another email address and am terribly sorry for it. Let me just post the link: https://docs.google.com/document/d/1Kvepb-v5Ta8ug_lLK1kZeexPNlpvj62K5iIF0fMuLyM/edit?usp=sharing On 03/25/2016 11:44 AM, John Criswell wrote: > Dear Jia, > > I don't see your proposal in the system. What is the title of your > proposal, and under what email

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, Based on an earlier discussion about existing pointer analyses in LLVM, I quickly hacked up a GSoC proposal on enabling cfl-aa by default. The decision to write it was made two days before the application deadline, hence the writing quality may not be very satisfactory: the background section could be less verbose, and the implementation section could be more formal. Also it

Dear Jia, I don't see your proposal in the system. What is the title of your proposal, and under what email address did you submit it? Regards, John Criswell On 3/23/16 4:09 PM, Jia Chen via llvm-dev wrote: > Dear llvm devs, > > Based on an earlier discussion about existing pointer analyses in > LLVM, I quickly hacked up a GSoC proposal on enabling cfl-aa by default. >

Hi all, I've started looking at the GlobalMerge pass, enabled by default on ARM and AArch64. I think we should reconsider that, at least for AArch64. As is, the pass just merges all globals together, in groups of 4KB (AArch64, 128B on ARM). At the time it was enabled, the general thinking was "it's almost free, it doesn't affect performance much, we might as well use it".

No, i mean the actual store instruction looks like "store i16 %conv22, i16* getelementptr inbounds ([16 x i16]* @pA, i64 0, i64 12), align 2, !tbaa !1" Not that the pointer operand comes from a GEP, but it is a constantexpr, whose opcode is GEP. It sucks that there is such a complex thing to be handled as a store operand directly , but such is life ... CFL-AA *should* treat this