search for: eembc

Hello LLVM, Does the community have bots or humans tracking code size for -Os builds? I've noticed troubling regressions lately. Sometime near Nov 5, the EEMBC bitmnp01 benchmark grew by 25% for ARMv7m and 35% for i586. That's ghastly. This week, the EEMBC matrix01 workload grew by 5% for ARMv7m and 3% for i586. Regards, -steve

...at linaro.org> wrote: > On 19 November 2015 at 19:08, Steve King via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Does the community have bots or humans tracking code size for -Os >> builds? > > Hi Steve, > > I still haven't got around doing a CI for EEMBC or SPEC on ARM. I do > track performance every release, but not code size at -Os. > >> I've noticed troubling regressions lately. Sometime near Nov >> 5, the EEMBC bitmnp01 benchmark grew by 25% for ARMv7m and 35% for >> i586. That's ghastly. This week, the EEMBC...

...rly comprehensive - we'd have to > > port that over or rewrite it and that would be a lot of work. > > 4. A very quick analysis last night indicated that ARM64 has > > implemented just under half of the optimizations we discovered opportunities > > for in SPEC and EEMBC. That's a fairly comprehensive number of > > optimizations, and they won't all be easy to port. Eric, You mention that there a quite a few optimization opportunities in SPEC 2000/ EEMBC. I am looking to optimize the Aarch64 backend. Could you please let me know the big optimization...

...mber 2015 at 19:08, Steve King via llvm-dev > <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: >> Does the community have bots or humans tracking code size for -Os >> builds? > > Hi Steve, > > I still haven't got around doing a CI for EEMBC or SPEC on ARM. I do > track performance every release, but not code size at -Os. > >> I've noticed troubling regressions lately. Sometime near Nov >> 5, the EEMBC bitmnp01 benchmark grew by 25% for ARMv7m and 35% for >> i586. That's ghastly. This week, the EEMBC...

If you could point me towards the correct location in the standard I would appreciate that - I didn't realize it wasn't acceptable to turn pointer-data to structs. My example is reduced from the EEMBC benchmarks where I ran into the problem, so I may have reduced it too far by accident (but I'm fairly sure they do not use __attribute__ or similar). Adding a __attribute__((aligned(...))) to my example did help, so thank you for that! Now to determine what to do about EEMBC... Thanks, Stephe...

...m the following sequence static int gbl_var; void foo() { for () { ...access gbl_var... } } into something like static int gbl_var; void foo() { int lcl_var; lcl_var = gbl_var; for () { ...access clc_var... } gbl_var = lcl_var; } This transformation helps a couple of EEMBC benchmarks on both Aarch64 and Hexagon backends. I was wondering if there is interest to get this optimization upstreamed or if there is a better way of doing this. Thanks, Sundeep Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

...choice if the known correctness issues (in ARM64) and lack of performance tuning (in AArch64) are addressed. However much more work has to be done to catch up with GCC 4.9 middle-end and backend optimizations. Benchmark ARM64 vs GCC 4.9 % ARM64 vs AArch64 % ARM64 vs AArch64 patched % EEMBC (no consumer) geomean -17 1 -2 EEMBC (consumer only) geomean -21 -2 -5 Linpack Double -29 45 -1 Linpack Single -51 40 1 SPEC2000 geomean -6 0 1 Thanks, Ana. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]...

...tricky. 3. The conditional compare pass is fairly comprehensive - we'd have to port that over or rewrite it and that would be a lot of work. 4. A very quick analysis last night indicated that ARM64 has implemented just under half of the optimizations we discovered opportunities for in SPEC and EEMBC. That's a fairly comprehensive number of optimizations, and they won't all be easy to port. The big pain issues I see going the other way, from AArch64 to ARM64 are: 1. Functional regressions. These are fairly easy to detect - we have a bunch of test suites and codegen faults are easy to s...

...gt; > port that over or rewrite it and that would be a lot of work. > > > > 4. A very quick analysis last night indicated that ARM64 has > > > > implemented just under half of the optimizations we discovered > > opportunities > > > > for in SPEC and EEMBC. That's a fairly comprehensive number of > > > > optimizations, and they won't all be easy to port. > > Eric, > > You mention that there a quite a few optimization opportunities in SPEC > > 2000/ EEMBC. > > I am looking to optimize the Aarch64 backend. C...

...choice if the known correctness issues (in ARM64) and lack of performance tuning (in AArch64) are addressed. However much more work has to be done to catch up with GCC 4.9 middle-end and backend optimizations. Benchmark ARM64 vs GCC 4.9 % ARM64 vs AArch64 % ARM64 vs AArch64 patched % EEMBC (no consumer) geomean -17 1 -2 EEMBC (consumer only) geomean -21 -2 -5 Linpack Double -29 45 -1 Linpack Single -51 40 1 SPEC2000 geomean -6 0 1 Thanks, Ana. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu]...

On Fri, Oct 12, 2012 at 10:43 AM, Stephen McGruer <stephen.mcgruer at gmail.com> wrote: > I'm having trouble getting my backend to properly treat the situation where > a char* is converted into a struct, i.e. something like: > > char* pointer_representation = ...; > MyStruct* my_struct = (MyStruct*) pointer_representation; > my_struct->an_int_field = 5; > >

...have > to > > > port that over or rewrite it and that would be a lot of work. > > > 4. A very quick analysis last night indicated that ARM64 has > > > implemented just under half of the optimizations we discovered > opportunities > > > for in SPEC and EEMBC. That's a fairly comprehensive number of > > > optimizations, and they won't all be easy to port. > Eric, > You mention that there a quite a few optimization opportunities in SPEC > 2000/ EEMBC. > I am looking to optimize the Aarch64 backend. Could you please let me kn...

I'm having trouble getting my backend to properly treat the situation where a char* is converted into a struct, i.e. something like: char* pointer_representation = ...; MyStruct* my_struct = (MyStruct*) pointer_representation; my_struct->an_int_field = 5; When this occurs, LLVM seems to fold the struct and char* into one assembly 'object', which is perfectly fine. However, it also

...ke >> >> static int gbl_var; >> void foo() { >> int lcl_var; >> >> lcl_var = gbl_var; >> for () { >> ...access clc_var... >> } >> gbl_var = lcl_var; >> >> } >> >> This transformation helps a couple of EEMBC benchmarks on both Aarch64 and >> Hexagon backends. I was wondering if there is interest to get this >> optimization upstreamed or if there is a better way of doing this. >> >> Thanks, >> Sundeep >> >> Qualcomm Innovation Center, Inc. is a member of Code Au...

On Tue, May 30, 2017 at 1:40 AM Agabaria, Mohammed via llvm-dev < llvm-dev at lists.llvm.org> wrote: > We’re seeing nice improvements but also significant degradations on IA, > which we would like to investigate before the patch is committed. > > > > Major degradations we see: > > > > networking > > ip_pktcheckb1m -6.80 % > >

I wanted to confirm that my understanding of the situation is correct. For background, I've been working have an optimizer pass for a research architecture which works best when there are large basic blocks and good alias analysis results. I first noticed the issue in rgbcmy01 from eembc-1.1, but have created a simpler test case which demonstrates the same issue which is unencumbered by the EEMBC license. Consider this simple example program: #include <stdint.h> #include <stdio.h> void main_loop(int len, uint8_t *restrict input_buf, uint8_t *restrict output_buf) { i...

Hi all, A bunch of us met at EuroLLVM to discuss the planned merge of the two current AArch64 backends in the tree. The primary question was which backend should form the basis of the merge (since the core .td files aren't directly mergeable), with code being cherry-picked from the other on a case-by-case basis. There were factors to consider both ways, but I think the key points of interest

...<llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> Subject: RE: [llvm-dev] Enable vectorizer-maximize-bandwidth by default? Chandler> Have you considered contributing these benchmarks to the LLVM test suite? These benchmarks are not ours to contribute; they’re from the EEMBC standard, whose availability is similar in nature to that of SPEC. From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Chandler Carruth via llvm-dev Sent: Tuesday, May 30, 2017 23:07 To: Agabaria, Mohammed <mohammed.agabaria at intel.com<mailto:mohammed.agabaria at intel...

...Holdings emulator does this; I used it with great success to > profile an Advanced Encryption Standard encryptor a while back. It is indeed a useful piece of kit. We do a lot of our internal regression tests on it, and also run LLVM's regression tests every night on it (as well as PlumHall, EEMBC and SpecInt). Unfortunately it's not exactly software we can give away or give access to. ________________________________________ From: Don Quixote de la Mancha [quixote at dulcineatech.com] Sent: 13 October 2011 18:47 To: Joe Abbey Cc: Renato Golin; rajav at codeaurora.org; llvmdev at cs.uiuc...

...der might not be that big of a deal on SPEC, as it is on other types of code. So far, I haven't found SPEC being too good to judge overall compilers' performance, but specific micro-optimized features. Besides, hardware and software are designed nowadays based on some version of Dhrystone, EEMBC, SPEC or CoreMark, so it's not impossible to see 50% increase in performance with little changes in either. 4. The ILP scheduler has the worst execution times on FP2006 and the second > worst spill counts, although it is the default on x86-64. Is this > surprising? BTW, Dragon Egg sets...