search for: bitmnp01

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

...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 matrix01 workload grew by >> 5% for ARMv7m and 3% for i586. > > Hum, v7M is even lower priority for me at the moment. :) > > Though, I have to say, 25% is really bad. Can you bis...

...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 matrix01 workload grew by >> 5% for ARMv7m and 3% for i586. > > Hum, v7M is even lower priority for me at the moment. :) > > Though, I have to say, 25% is really bad. Can you bis...

On Tue, Jan 29, 2013 at 3:59 PM, Murali, Sriram <sriram.murali at intel.com> wrote: > Our benchmark results show that the compilation time performance improved by > ~0.5%. That's fairly small; what was the standard deviation, confidence interval, etc? -- Sean Silva

...01.14 403.gcc 100.00 100.33 429.mcf 100.00 100.37 433.milc 100.00 99.85 444.namd 100.00 100.28 445.gobmk 100.00 100.11 450.soplex 100.00 100.46 456.hmmer 100.00 100.29 458.sjeng 100.00 100.70 464.h264ref 100.00 102.10 470.lbm 100.00 100.07 471.omnetpp 100.00 100.36 bitmnp01 100.00 100.44 cjpegv2data6 100.00 100.76 idctrn01 100.00 99.83 libquake2 100.00 100.08 libquake_portable 100.00 100.02 libxcsoar 100.00 100.08 linpack 100.00 101.07 matrix01 100.00 100.28 nbench 100.00 100.76 tblook01 100.00 101.52 ttsprk01 100.00 100.82 Geomean 10...

Hello, This patch aims to improve compile time performance by increasing the SCEV vector size in LoopStrengthReduce. It is observed that the BaseRegs vector size is 4 in most cases, and elements are frequently copied when it is initialized as SmallVector<const SCEV *, 2> BaseRegs. Our benchmark results show that the compilation time performance improved by ~0.5%. Patch by Wan Xiaofei.

On Fri, Nov 20, 2015 at 5:06 PM, James Molloy <james at jamesmolloy.co.uk> wrote: > > Hi, > > We'd need to look precisely at what's causing the code size bloat. The midend commit pointed out by Steve shouldn't cause bloat in and of itself - it should reduce code size. It removes a load of stores and branches. > > I know a backend change I made to ARM isn't