Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751883AbdLQInv (ORCPT ); Sun, 17 Dec 2017 03:43:51 -0500 Received: from mail.free-electrons.com ([62.4.15.54]:59530 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750868AbdLQInr (ORCPT ); Sun, 17 Dec 2017 03:43:47 -0500 Date: Sun, 17 Dec 2017 09:43:45 +0100 From: Boris Brezillon To: Marek Vasut Cc: Arnd Bergmann , David Woodhouse , Brian Norris , Richard Weinberger , Cyrille Pitchen , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH] mtd: cfi: convert inline functions to macros Message-ID: <20171217094345.3d327c54@bbrezillon> In-Reply-To: References: <20171011135419.3492681-1-arnd@arndb.de> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2456 Lines: 52 Hi Marek, On Wed, 11 Oct 2017 23:34:33 +0200 Marek Vasut wrote: > On 10/11/2017 03:54 PM, Arnd Bergmann wrote: > > The map_word_() functions, dating back to linux-2.6.8, try to perform > > bitwise operations on a 'map_word' structure. This may have worked > > with compilers that were current then (gcc-3.4 or earlier), but end > > up being rather inefficient on any version I could try now (gcc-4.4 or > > higher). Specifically we hit a problem analyzed in gcc PR81715 where we > > fail to reuse the stack space for local variables. > > > > This can be seen immediately in the stack consumption for > > cfi_staa_erase_varsize() and other functions that (with CONFIG_KASAN) > > can be up to 2200 bytes. Changing the inline functions into macros brings > > this down to 1280 bytes. Without KASAN, the same problem exists, but > > the stack consumption is lower to start with, my patch shrinks it from > > 920 to 496 bytes on with arm-linux-gnueabi-gcc-5.4, and saves around > > 1KB in .text size for cfi_cmdset_0020.c, as it avoids copying map_word > > structures for each call to one of these helpers. > > > > With the latest gcc-8 snapshot, the problem is fixed in upstream gcc, > > but nobody uses that yet, so we should still work around it in mainline > > kernels and probably backport the workaround to stable kernels as well. > > We had a couple of other functions that suffered from the same gcc bug, > > and all of those had a simpler workaround involving dummy variables > > in the inline function. Unfortunately that did not work here, the > > macro hack was the best I could come up with. > > > > It would also be helpful to have someone to a little performance testing > > on the patch, to see how much it helps in terms of CPU utilitzation. > > > > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715 > > Cc: stable@vger.kernel.org > > Signed-off-by: Arnd Bergmann > > Don't you lose type-checking with this conversion to macros ? > Yes, we loose strict type checking, but if you look at the code, you'll see that the macros do (valN).x[i], so, if valN is not a struct or a union containing a field named x, the compiler will complain. That should save us from devs passing random arguments to those macros. Anyway, this code is not seeing a lot of changes lately, so I wouldn't be so worried by the lack of strict type-checking implied by this transition to macros. Regards, Boris