search for: a57

Hello everybody, I'm reading the .td files defining the Cortex-A57 processor, which is a subtarget of AArch64 target, and there is something confusing me in the `AArch64SchedA57.td` file. In the top of `AArch64SchedA57.td`, various processor resource are defined, as follows ``` def A57UnitB : ProcResource<1>; // Type B micro-ops def A57UnitI : Proc...

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 while.body.lr.ph: %arrayidx72 = getelementptr inbounds double* %11, i64 1 LICM hoisting to while.body.lr.ph: %arrayidx8...

...: > >> 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 while.body.lr.ph: %arrayidx72 = getelementptr >> inbounds double* %11, i64 1 &gt...

...ge on execution speed? I think the main reason to be hesitant to change the default CPU for ARM to -mcpu=generic is the potential impact on performance of generated code. I've measured quite a wide selection of benchmarks with this change, on the following cores: Cortex-A9, Cortex-A53, Cortex-A57, Cortex-A72. Impact on execution speed, for each core, when using -march=armv7a, after changing the default cpu from cortex-a8 to generic is as follows. A positive numbers means speedup, a negative number means slow-down. These are the geomean results over 350 programs coming from benchmark suites...

...ng 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 while.body.lr.ph: %arrayidx72 = getelementptr >>...

...rom:* George Burgess IV [mailto:george.burgess.iv at gmail.com] > *Sent:* Wednesday, January 14, 2015 10:31 AM > *To:* Daniel Berlin > *Cc:* Nick Lewycky; Ana Pazos; Jiangning Liu; LLVM Developers Mailing List > *Subject:* Re: [LLVMdev] question about enabling cfl-aa and collecting > a57 numbers > > > > 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...

...> >>>>>> 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 while.body.lr.ph: %arrayidx72 = getelementptr inbounds double* %11, i64...

...ge on execution speed? I think the main reason to be hesitant to change the default CPU for ARM to -mcpu=generic is the potential impact on performance of generated code. I've measured quite a wide selection of benchmarks with this change, on the following cores: Cortex-A9, Cortex-A53, Cortex-A57, Cortex-A72. Impact on execution speed, for each core, when using -march=armv7a, after changing the default cpu from cortex-a8 to generic is as follows. A positive numbers means speedup, a negative number means slow-down. These are the geomean results over 350 programs coming from benchmark suites...

...om:* Daniel Berlin [mailto:dberlin at dberlin.org] > *Sent:* Wednesday, January 14, 2015 1:10 PM > *To:* Ana Pazos > *Cc:* George Burgess IV; Nick Lewycky; Jiangning Liu; LLVM Developers > Mailing List > > *Subject:* Re: [LLVMdev] question about enabling cfl-aa and collecting > a57 numbers > > > > 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: > >...

So far, all I have tried is -O3 and with & without "-mcpu=cortex-a57". I'm new to LLVM so I'm not familiar with what optimization flags are available. I tried poking around in the LLVM documentation but haven't found a definitive list. The clang man page is skimpy on details. From: Arnaud A. de Grandmaison [mailto:arnaud.degrandmaison at arm.com] S...

On aarch64 with -M virt, the default CPU model is cortex-a15 (a 32 bit CPU). This is IMHO a stupid default, but there we are. Therefore most users will need to pass the `-cpu cortex-a53' or `-cpu cortex-a57' flag to qemu, depending on a complex formula of their host CPU and if they are using TCG or not. However I cannot work out how to pass this through libvirt. The obvious one would be: <cpu><model>cortex-a57</model></cpu> This passes `-cpu host' which is both wr...

...much appreciate any suggestions ============Input script: backtestFormula<-SPX~A1+A2+A3+A4+A5+A6+A7+A8+A9+A10+A11+A12+A13+A14+A15+A16+A17+A18+A19+A20+A21+A22+A23+A24+A25+A26+A27+A28+A29+A30+A31+A32+A33+A34+A35+A36+A37+A38+A39+A40+A41+A42+A43+A44+A45+A46+A47+A48+A49+A50+A51+A52+A53+A54+A55+A56+A57+A58+A59+A60+A61+A62+A63+A64+A65+A66+A67+A68+A69+A70+A71+A72+A73+A74+A75+A76+A77+A78+A79+A80+A81+A82+A83+A84+A85+A86+A87+A88+A89+A90+A91+A92+A93+A94+A95+A96+A97+A98+A99+A100+A101+A102+A103+A104+A105+A106+A107+A108+A109+A110+A111+A112+A113 benchmarkName = as.character(backtestFormula)[2] print(as.cha...

% clang -S -O3 -mcpu=cortex-a57 -ffast-math -Rpass-analysis=loop-vectorize dot.c dot.c:15:1: remark: loop not vectorized: value that could not be identified as reduction is used outside the loop [-Rpass-analysis=loop-vectorize] } ^ dot.c:15:1: note: could not determine the original source location for :0:0 I found “llvm-as...

Hi Andy, Dave, I've been doing a bit of experimentation trying to understand the schedmodel a bit better and improving modelling of FDIV (on Cortex-A57). FDIV is not pipelined, and blocks other FDIV operations (FDIVDrr and FDIVSrr). This seems to be already semi-modelled, with a "ResourceCycles=[18]" line in the SchedWriteRes for this instruction. This doesn't seem to work (a poor schedule is produced) so I changed it to also requir...

...Finkel" <hfinkel at anl.gov>, "Jiangning Liu" > <Jiangning.Liu at arm.com>, "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Friday, January 30, 2015 8:15:55 AM > Subject: Re: [LLVMdev] question about enabling cfl-aa and collecting a57 numbers > > > > I'm not exactly thrilled about the size of this diff -- I'll happily > break it up into more manageable bits later today, because some of > it is test fixes, another bit is a minor bug fix, etc. Yes, please break it into independent parts. > >...

...iu" <Jiangning.Liu at arm.com>, "LLVM Developers Mailing > List" <llvmdev at cs.uiuc.edu>, "Daniel Berlin" <dberlin at dberlin.org> > Sent: Friday, January 30, 2015 10:29:07 AM > Subject: Re: [LLVMdev] question about enabling cfl-aa and collecting a57 numbers > > > > I had thought that the case that Danny had looked at had a constant > > GEP, and so this constant might alias with other global pointers. > > How is that handled now? > That issue had to do with that we assumed that for all arguments of a > given Inst...

...uot; <llvmdev at cs.uiuc.edu <mailto:llvmdev at cs.uiuc.edu>>, "Daniel Berlin" <dberlin at dberlin.org <mailto:dberlin at dberlin.org>> >> Sent: Friday, January 30, 2015 10:29:07 AM >> Subject: Re: [LLVMdev] question about enabling cfl-aa and collecting a57 numbers >> >> >>> I had thought that the case that Danny had looked at had a constant >>> GEP, and so this constant might alias with other global pointers. >>> How is that handled now? >> That issue had to do with that we assumed that for all arguments...

I'm using Fedora 22 and gcc 4.9.2 to run llvm 3.5.1 on an ARM Juno reference box (cortex A53 & A57). I tried compiling some simple functions like dot product and axpy() into assembly to see if any of the SIMD instructions were generated (they weren't). Perhaps I'm missing some compiler flag to enable it. Does anyone know what the status is for aarch64 generating SIMD instructions? Anyon...

Hi, I was looking at some AArch64 benchmarks and noticed some simple cases where addresses are being folded into the address mode computations and was curious as to why. In particular, consider the following simple example: void f2(unsigned long *x, unsigned long c) { x[c] *= 2; } This generates: lsl x8, x1, #3 ldr x9, [x0, x8] lsl x9, x9, #1 str x9, [x0, x8] Given the two

...nkel at anl.gov>, "Jiangning Liu" > > <Jiangning.Liu at arm.com>, "LLVM Developers Mailing List" < > llvmdev at cs.uiuc.edu> > > Sent: Friday, January 30, 2015 8:15:55 AM > > Subject: Re: [LLVMdev] question about enabling cfl-aa and collecting a57 > numbers > > > > > > > > I'm not exactly thrilled about the size of this diff -- I'll happily > > break it up into more manageable bits later today, because some of > > it is test fixes, another bit is a minor bug fix, etc. > > Yes, please break...