From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752617AbdIWBdw (ORCPT ); Fri, 22 Sep 2017 21:33:52 -0400 Received: from smtprelay0024.hostedemail.com ([216.40.44.24]:55574 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752553AbdIWBdu (ORCPT ); Fri, 22 Sep 2017 21:33:50 -0400 X-Session-Marker: 6A6F6540706572636865732E636F6D X-Spam-Summary: 50,0,0,,d41d8cd98f00b204,joe@perches.com,:::::::::::::,RULES_HIT:41:355:379:541:599:800:960:967:973:988:989:1260:1277:1311:1313:1314:1345:1359:1373:1437:1515:1516:1518:1534:1542:1593:1594:1711:1730:1747:1777:1792:2110:2198:2199:2393:2525:2553:2560:2563:2682:2685:2828:2859:2915:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3355:3622:3865:3866:3867:3868:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4031:4321:4605:5007:6117:6119:7903:8603:8985:9025:10004:10400:10848:11232:11658:11914:12043:12555:12740:12760:12895:12986:13439:14181:14659:14721:21080:21324:21433:21434:21611:21627:30012:30054:30060:30090:30091,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:,MSBL:0,DNSBL:none,Custom_rules:0:0:0,LFtime:2,LUA_SUMMARY:none X-HE-Tag: north75_3e53d4a8d4412 X-Filterd-Recvd-Size: 3893 Message-ID: <1506130426.12311.51.camel@perches.com> Subject: Re: [PATCH] lib/lz4: make arrays static const, reduces object code size From: Joe Perches To: Arnd Bergmann Cc: Colin Ian King , Christophe JAILLET , Sven Schmidt <4sschmid@informatik.uni-hamburg.de>, Andrew Morton , kernel-janitors@vger.kernel.org, Linux Kernel Mailing List Date: Fri, 22 Sep 2017 18:33:46 -0700 In-Reply-To: References: <20170921221939.20820-1-colin.king@canonical.com> <5aab65d9-6da6-c770-b5aa-9edbdda31dec@wanadoo.fr> <250fe35e-77d3-a9c0-5613-ce1c65f4cb7f@canonical.com> <1506100881.12311.41.camel@perches.com> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.22.6-1ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2017-09-22 at 21:17 +0200, Arnd Bergmann wrote: > On Fri, Sep 22, 2017 at 7:21 PM, Joe Perches wrote: > > On Fri, 2017-09-22 at 09:48 +0200, Arnd Bergmann wrote: > > > On Fri, Sep 22, 2017 at 1:11 AM, Colin Ian King > > > text data bss dec hex filename > > > 18220 176 0 18396 47dc build/tmp/lib/lz4/lz4_decompress-after.o > > > 22297 0 0 22297 5719 build/tmp/lib/lz4/lz4_decompress-before.o > > > > Perhaps not so much a gcc bug as an opportunity > > for gcc to add an additional optimization. > > > > gcc would have to verify that the const array is > > not initialized with some variable or argument like: > > > > int foo(int a) > > { > > const int array[] = {1, a}; > > ... > > } > > It depends. With a 10KB different in .text size, my guess is that this > is a case where gcc does the right optimization in principle, but > fails to do what was intended in some corner cases. Maybe/maybe not. > I just cross-checked by building with clang, there the patch has > no impact on code size, it is 24929 bytes with or without the patch. > > Looking at other versions of (x86) gcc, I see .text sizes of > > after before > gcc-3.4.6 10855 12977 > gcc-4.0.4 11088 11088 > gcc-4.1.3 10973 10973 > gcc-4.2.5 11183 11183 > gcc-4.3.6 15501 17724 Interesting this was apparently deoptimized at version 4.3. Glancing at the release notes doesn't seem to indicate anything obvious. https://gcc.gnu.org/gcc-4.3/changes.html > gcc-4.4.7 13337 15693 > gcc-4.5.4 13162 15491 > gcc-4.6.4 14846 17302 > gcc-4.7.4 14187 16294 > gcc-4.8.5 16591 18730 > gcc-4.9.4 19582 21995 > gcc-5.4.1 18294 22510 > gcc-6.1.1 20487 25172 > gcc-6.3.1 20487 25172 > gcc-7.0.0 20351 31789 > gcc-7.0.1 20351 24966 > gcc-7.1.1 20383 24982 > gcc-8.0.0 20686 25065 > > It seems whatever happened in early versions of gcc-7 has since > improved, and it probably was a bug since older and newer versions > create similar code size (I have not looked at the actual object code). > > The 5K difference in gcc-5 and higher still seems like a lot. It would > also be interesting to look at the decompression performance of > this code witth the different compilers to see if it got better or worse. yup > Most likely, gcc got better at inlining and unrolling parts of the > algorithm, but sometimes an object file that doubles or triples in > size is an indication that the compiler did something really bad. yup[2] cheers, Joe