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
Renato Golin via llvm-dev
2015-Nov-19 21:10 UTC
[llvm-dev] Recent -Os code size regressions
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 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 bisect to see which commit was that? cheers, --renato
On Thu, Nov 19, 2015 at 1:10 PM, Renato Golin <renato.golin 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 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 bisect to see which > commit was that?Hi Renato, Thanks for advising. The commit is: [llvm] r252152 - [SimplifyCFG] Tweak heuristic for merging conditional stores Can this be reverted until the surprising code size impact is understood? I'm about to leave for the week, so I can't delve further anytime soon. Regards, -steve
Possibly Parallel Threads
- Recent -Os code size regressions
- Recent -Os code size regressions
- Recent -Os code size regressions
- [LLVMdev] [Patch][Review Requested][Compilation Time] Avoid frequent copy of elements in LoopStrengthReduce
- [LLVMdev] Generate code for ARM Cortex m0, m3, and m4.