Smith, Kevin B via llvm-dev
2015-Nov-21 00:50 UTC
[llvm-dev] Recent -Os code size regressions
Maybe adjust this to be different for –Os, -Oz than for –O2? Kevin Smith From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of James Molloy via llvm-dev Sent: Friday, November 20, 2015 4:05 PM To: Steve King <steve at metrokings.com>; Renato Golin <renato.golin at linaro.org> Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] Recent -Os code size regressions Hi Steve, That commit gives significant performance improvements, so I'm not happy reverting it because of the code size increase. A lot of the code size increase is backend dependent, and I have a set of patches that improves the codegen drastically on ARM at least. The midend is generating better code, and more optimisable code (and it's about 30% more performance too). James On Sat, 21 Nov 2015 at 00:01, Steve King <steve at metrokings.com<mailto:steve at metrokings.com>> wrote: On Thu, Nov 19, 2015 at 1:10 PM, Renato Golin <renato.golin at linaro.org<mailto:renato.golin at linaro.org>> wrote:> On 19 November 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 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151121/7657bea4/attachment.html>
James Molloy via llvm-dev
2015-Nov-21 01:06 UTC
[llvm-dev] Recent -Os code size regressions
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 behaving as well as it could, and I have patches to fix that. Speculatively reverting midend patches isn't the best way to approach this, in my opinion! :) James On Sat, 21 Nov 2015 at 00:50, Smith, Kevin B <kevin.b.smith at intel.com> wrote:> Maybe adjust this to be different for –Os, -Oz than for –O2? > > > > Kevin Smith > > > > *From:* llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] *On Behalf Of *James > Molloy via llvm-dev > *Sent:* Friday, November 20, 2015 4:05 PM > *To:* Steve King <steve at metrokings.com>; Renato Golin < > renato.golin at linaro.org> > *Cc:* llvm-dev <llvm-dev at lists.llvm.org> > *Subject:* Re: [llvm-dev] Recent -Os code size regressions > > > > Hi Steve, > > That commit gives significant performance improvements, so I'm not happy > reverting it because of the code size increase. A lot of the code size > increase is backend dependent, and I have a set of patches that improves > the codegen drastically on ARM at least. The midend is generating better > code, and more optimisable code (and it's about 30% more performance too). > > James > > On Sat, 21 Nov 2015 at 00:01, Steve King <steve at metrokings.com> wrote: > > 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 > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151121/282a3835/attachment.html>
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. Themidend 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 behaving as well as it could,and I have patches to fix that. Speculatively reverting midend patches isn't the best way to approach this, in my opinion! :)> For i586, the effect of r252152 seems to cause cmoves instead of branches. Code size increase is +35% for i586. Unfortunately the object files are wildly different in a way that does not seem to occur in other workloads. I tried to clip a concise before and after case. Before : As a reference point, I found OR $0x408 and OR $0x810 in close proximity. 278: 81 ca 10 08 00 00 or $0x810,%edx 27e: 89 10 mov %edx,(%eax) 280: f6 c1 40 test $0x40,%cl 283: 74 08 je 28d <t_run_test+0x28d> 285: 81 ca 08 04 00 00 or $0x408,%edx 28b: 89 10 mov %edx,(%eax) 28d: 84 c9 test %cl,%cl 28f: 0f 89 34 01 00 00 jns 3c9 <t_run_test+0x3c9> After r252152: Note that the OR $0x408 and OR $0x810 come now in reverse order. 35d: 81 c9 08 04 00 00 or $0x408,%ecx 363: 89 4c 24 28 mov %ecx,0x28(%esp) 367: 89 df mov %ebx,%edi 369: 83 e7 10 and $0x10,%edi 36c: 89 7c 24 20 mov %edi,0x20(%esp) 370: 0f 45 d1 cmovne %ecx,%edx 373: 89 d7 mov %edx,%edi 375: 81 cf 10 08 00 00 or $0x810,%edi 37b: 89 7c 24 14 mov %edi,0x14(%esp) 37f: 89 d9 mov %ebx,%ecx 381: 83 e1 20 and $0x20,%ecx 384: 89 4c 24 1c mov %ecx,0x1c(%esp) 388: 0f 45 d7 cmovne %edi,%edx 38b: 89 d7 mov %edx,%edi HTH, -steve -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151120/e41234db/attachment-0001.html>
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. >Hi James, Sounds like your patch should have been the best of both worlds, so can you investigate the -Os code size mystery? Does the problem even occur in your tests? If you don't have time, then Kevin's idea to bypass the problem for now with an optsize check makes sense to me. Regards, -steve