search for: apazos

...talias should be getting passed down the stack, so either that is not happening or CFL aa is giving better answers and something does worse with those better answers. I'll take a look this evening >>>>> >>>>>> On Jan 13, 2015 3:58 PM, "Ana Pazos" <apazos at codeaurora.org> wrote: >>>>>> Hi folks, >>>>>> >>>>>> Moving the discussion to llvm.dev. >>>>>> >>>>>> None of the changes we talked earlier help. >>>>>> >>>>>> Fin...

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) to be removed. > > Thanks, > > Ana. > > > > *From:* George Burgess IV [ma...

...Chandler Carruth Cc: Jiangning Liu; Pazos, Ana; Ana Pazos; Daniel Berlin; George Burgess IV Subject: Re: question about enabling cfl-aa and collecting a57 numbers ----- Original Message ----- > From: "Chandler Carruth" <chandlerc at gmail.com> > To: "Ana Pazos" <apazos at codeaurora.org>, "Daniel Berlin" <dberlin at dberlin.org>, "George Burgess IV" > <george.burgess.iv at gmail.com>, "Hal Finkel" <hfinkel at anl.gov> > Cc: "Jiangning Liu" <Jiangning.Liu at arm.com>, "Ana Pazos" &...

...g 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 something does worse with those better answers. I'll take a look this > evening > On Jan 13, 2015 3:58 PM, "Ana Pazos" <apazos at codeaurora.org> wrote: > >> 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...

...s should be getting passed down >>> the stack, so either that is not happening or CFL aa is giving better >>> answers and something does worse with those better answers. I'll take a >>> look this evening >>> On Jan 13, 2015 3:58 PM, "Ana Pazos" <apazos at codeaurora.org> wrote: >>> >>>> 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...

...eed to be processed :P). This was causing unnecessary aliasing. 4. Adds a regression test to must-and-partial 5. Fixes the pass ordering 6. Does not alias non-pointer arguments to random things :) 7. Fixes the CFL test cases that break with above. On Thu, Jan 15, 2015 at 11:33 AM, Ana Pazos <apazos at codeaurora.org> wrote: > Daniel, don’t we need to fix the order of invoking alias analyses in > lib/Transforms/IPO/PassManagerBuilder.cpp as well? > > > > Your patch fixed the order in lib/CodeGen/Passes.cpp and the delegation > code in lib/Analysis/CFLAliasAnalysis.cpp....

...32-bit variable shifts on RV64 > > > Others that would be good, but perhaps not so important to get in: > > r352240 | asb | 2019-01-25 13:06:47 -0800 (Fri, 25 Jan 2019) | 7 lines > [RISCV] Add another potential combine to {double,float}-bitmanip-dagcombines.ll > > r352237 | apazos | 2019-01-25 12:22:49 -0800 (Fri, 25 Jan 2019) | 3 lines > Reapply: [RISCV] Set isAsCheapAsAMove for ADDI, ORI, XORI, LUI > > r352211 | asb | 2019-01-25 08:04:04 -0800 (Fri, 25 Jan 2019) | 6 lines > [RISCV][NFC] s/f32/f64 in double-arith.ll > > r352199 | asb | 2019-01-25 06:33:08...

...ay, April 08, 2014 4:46 PM To: Ana Pazos Cc: Tim Northover; LLVM Developers Mailing List Subject: Re: [LLVMdev] Proposal: AArch64/ARM64 merge from EuroLLVM Hi Ana, could you share the SPEC2000 data per suite and per benchmark? Thanks Gerolf On Apr 8, 2014, at 1:33 AM, Ana Pazos <apazos at codeaurora.org> wrote: Hi folks, As Tim pointed out, we recently had the opportunity to collect 64-bit benchmark performance data for GCC 4.9, AArch64 and ARM64 compilers on a real hardware. It is a cortex-a53 device. Due to proprietary reasons we cannot share the full hardware confi...

Ping From: Mandeep Singh Grang [mailto:mgrang at codeaurora.org] Sent: Tuesday, February 03, 2015 4:34 PM To: 'llvmdev at cs.uiuc.edu' Cc: 'ghoflehner at apple.com'; 'apazos at codeaurora.org'; mgrang at codeaurora.org Subject: Question on Machine Combiner Pass Hi, In the file lib/CodeGen/MachineCombiner.cpp I see that in the function MachineCombiner::preservesCriticalPathLen we try to determine whether the new combined instruction lengthens the critical p...

Dear testers, 8.0.0-rc1 was just tagged (from the branch at r351980). It took a little longer than planned, but it's looking good. Please run the test script, share your results, and upload binaries. I'll get the source tarballs and docs published as soon as possible, and binaries as they become available. Thanks, Hans

Hi, I am experimenting with creating instructions that write into virtual registers that use the ARM GPRPair register class in Pre-RA phase. During register allocation, I hit an assertion because the code is not in SSA form: lib/CodeGen/MachineRegisterInfo.cpp:271: llvm::MachineInstr* llvm::MachineRegisterInfo::getVRegDef(unsigned int) const: Assertion `(I.atEnd() || llvm::next(I) ==

Hi folks, As Tim pointed out, we recently had the opportunity to collect 64-bit benchmark performance data for GCC 4.9, AArch64 and ARM64 compilers on a real hardware. It is a cortex-a53 device. Due to proprietary reasons we cannot share the full hardware configuration. The preliminary results were shared at the hackers lab at EuroLLVM yesterday. For those who could not make it, below is

...he global attribute is not being fully propagated around or something. On Fri Jan 23 2015 at 4:45:34 PM Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Daniel Berlin" <dberlin at dberlin.org> > > To: "Ana Pazos" <apazos at codeaurora.org>, "George Burgess IV" < > george.burgess.iv at gmail.com> > > Cc: "Jiangning Liu" <Jiangning.Liu at arm.com>, "LLVM Developers Mailing > List" <llvmdev at cs.uiuc.edu>, "Hal Finkel" > > <hfinkel at a...

I just tried to apply the patches to the community clang and llvm tips and there are conflicts. Do you guys plan to rebase the patches? I vote for importing the ARM64 backend into the public tree as soon as possible. Thanks, Ana. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Kristof Beyls Sent: Friday, March 28, 2014 2:44

...iel Berlin" <dberlin at dberlin.org> > > To: "Hal Finkel" <hfinkel at anl.gov> > > Cc: "Jiangning Liu" <Jiangning.Liu at arm.com>, "LLVM Developers Mailing > List" <llvmdev at cs.uiuc.edu>, "Ana Pazos" > > <apazos at codeaurora.org>, "George Burgess IV" < > george.burgess.iv at gmail.com> > > Sent: Friday, January 23, 2015 7:14:24 PM > > Subject: Re: [LLVMdev] question about enabling cfl-aa and collecting a57 > numbers > > > > > > No, i mean the actual s...

(sorry for the wide distribution, but this impacts Clang users quite a bit) It's come up a few times in reviews of CFL-AA (a new alias analysis for LLVM), so I wanted to write down what I think the current state actually is for AA pass ordering, why, and how it should look eventually. I may have some bugs here, so please correct me if I miss anything. And I'd love thoughts about the end

...the global. 2. Something is either busted in querying or in attributes for stores that have geps directly as their pointer value. I will work up a separate patch for this issue unless someone thinks i should shoehorn it into the existing patch. On Fri Jan 23 2015 at 12:52:02 PM Ana Pazos <apazos at codeaurora.org> wrote: > Hi Daniel, > > > > There are correctness issues with the latest patch (from Wed 1/21/2015 > 11:10 AM with “Updated testcases to have MayAlias/note issues as FIXME”). > > > > I looked at one of the failures and it has to do with disambigu...

So, I can make all these testcases work, but it's a little tricky (it involves tracking some things, like GEP byte range, and then checking bases and using getObjectSize, much like BasicAA does). Because i really don't want to put that much "not well tested" code in a bugfix, and honestly, i'm not sure we will catch any cases here that BasicAA does not, i've attached a

Works for me On Thu, Jan 22, 2015 at 8:27 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > We should use graph edges, so we can do something better at set build time > :) > > > On Thu Jan 22 2015 at 5:20:46 PM George Burgess IV < > george.burgess.iv at gmail.com> wrote: > >> > Should we be added an edge from the inttoptr to all other pointer >>