search for: liujiangning1

----- 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 7:58:59 PM > Subject: Re: [LLVMdev] Testing the new CFL alias analysis > > I filed bugzilla pr20954. Thanks! -Hal > > > -Gerolf > > >...

...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" <ghoflehner at apple.com> >> To: "Jiangning Liu" <liujiangning1 at gmail.com>, "George Burgess IV" <george.burgess.iv at gmail.com>, "Hal Finkel" >> <hfinkel at anl.gov> >> Cc: "LLVM Dev" <llvmdev at cs.uiuc.edu> >> Sent: Sunday, September 14, 2014 12:15:02 AM >> Subject: Re: [LLVMdev] T...

It seems the crash of llvm/clang build on aarch64 Debian has been fixed by r220941. Thanks, -Jiangning 2014-11-05 8:45 GMT+08:00 Jiangning Liu <liujiangning1 at gmail.com>: > The versions I'm using right now are > > * gcc: (Debian/Linaro 4.9.1-14) 4.9.1 > * libstdc++: libstdc++.so.6.0.20 > > Thanks, > -Jiangning > > 2014-11-05 4:46 GMT+08:00 Chris Bieneman <beanz at apple.com>: > >> Adding Jiangning Liu...

...l likely boil down to increased register pressure. Looks like the current performance numbers pose a good challenge for gaining new and refreshing insights into our heuristics (and for smoothing out the implementation along the way). Cheers Gerolf On Sep 12, 2014, at 1:27 AM, Jiangning Liu <liujiangning1 at gmail.com> wrote: > Hi Hal, > > I run on SPEC2000 on cortex-a57(AArch64), and got the following results, > > (It is to measure run-time reduction, and negative is better performance) > > spec.cpu2000.ref.183_equake 33.77% > spec.cpu2000.ref.179_art 13.44% > spec...

...ter from malloc is used to compare with null and finally affect the return value. So this optimization may change the original semantic. Thanks, Kevin 2015-04-01 12:52 GMT+08:00 David Majnemer <david.majnemer at gmail.com>: > > > On Tue, Mar 31, 2015 at 7:59 PM, Jiangning Liu <liujiangning1 at gmail.com> > wrote: > >> Hi Mats, >> >> I think Kevin's point is malloc can return 0, if malloc/free pair is >> optimized way, the semantic of the original would be changed. >> >> On the other hand, malloc/free are special functions, but programme...

Hi Mats, I think Kevin's point is malloc can return 0, if malloc/free pair is optimized way, the semantic of the original would be changed. On the other hand, malloc/free are special functions, but programmers can still define their own versions by not linking std library, so we must assume malloc/free always have side-effect like other common functions, unless we know we will link std

This sounds reasonable. Thanks, all. > - CSE of ADRP optimization (Jiangning) Quentin may have some input here. He’s done quite a lot of optimizations for ADRP sequences. -Jim On Apr 12, 2014, at 12:08 AM, Tim Northover <t.p.northover at gmail.com> wrote: > Hi again, > > Having heard no howls of protest, those of us remaining on the > Wednesday decided to get down to

Hi Jiangning, On Apr 15, 2014, at 11:12 PM, Jiangning Liu <liujiangning1 at gmail.com> wrote: > Hi Quentin, > > Thanks for your feedback! >> ​ARM64 generates pseudo instructions ARM64::MOVaddr and friends in ISEL stage, which intends to guarantee address serialization (page address + in-page address), and exposes adrp finally by pass ExpandPseudoInst...

Hi Tim, I just read this thread and I see that you mentioned the buildbot and my name. > - LLVM test suite enabled in the buildbot and testing ARM64 (Gabor) What exactly I can do to help you with the merge process? Best regards, Gabor Ballabas -------------- next part -------------- An HTML attachment was scrubbed... URL:

Hi Ahmed, Yes. I'd share with Kristof and Renato's concerns, and the impact/dependence upon link-time tool should be clarified before disabling this pass. On the other hand, actually the test on our hardware shows disabling this pass without LTO considered, some spec benchmarks would have big regressions, (positive is bad) spec.cpu2000.ref.253_perlbmk 3.27% spec.cpu2000.ref.254_gap

Hi Jiangning, On Apr 14, 2014, at 10:31 PM, Jiangning Liu <liujiangning1 at gmail.com> wrote: > Hi Jim, > > 2014-04-15 4:28 GMT+08:00 Jim Grosbach <grosbach at apple.com>: > This sounds reasonable. Thanks, all. > > > - CSE of ADRP optimization (Jiangning) > > Quentin may have some input here. He’s done quite a lot of optimizations...

> - Inline ASM (I think Eric said at the Hackers Lab that he might be > willing to do this) I am, yes. > - For others who want to help test, compiling and running your > codebases on QEMU (no crypto extensions) Some reasonable description of how this works would be awesome. > > - Feature parity - to the level found in the ARM64 and AArch64 backends today As a note this

Hi, For the following case, $ cat bad1.ll target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:64:128-a0:0:64-n32-S64" define internal void @test(i32 %v) { entry: %tmp = alloca i32, align 4 store i32 %v, i32* %tmp, align 4 %0 = bitcast i32* %tmp to <2 x i8>* %1 = load <2 x i8>* %0, align 4 ret void } I

Hello everyone, One of Google's summer interns, George Burgess IV, created an implementation of the CFL pointer-aliasing analysis algorithm, and this has now been added to LLVM trunk. Now we should determine whether it is worthwhile adding this to the default optimization pipeline. For ease of testing, I've added the command line option -use-cfl-aa which will cause the CFL analysis to be

Adding Jiangning Liu to the thread. Jiangning reported a similar issue on the llvm-commits list on Debian aarch64. In general it sounds like std::call_once may not really be bug free. Jiangning, can you please provide your gcc/libstdc++ version? Thanks, -Chris > On Nov 4, 2014, at 9:38 AM, Bill Schmidt <wschmidt at linux.vnet.ibm.com> wrote: > > On Tue, 2014-11-04 at 12:17

Hi, We are now about halfway between the 3.4 and 3.5 releases, and I would like to start preparing for a 3.4.1 release. Here is my proposed release schedule: Mar 26 - April 9: Identify and backport additional bug fixes to the 3.4 branch. April 9 - April 18: Testing Phase April 18: 3.4.1 Release How you can help: - If you have any bug fixes you think should be included to 3.4.1, send me an