[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6C490CCD-32E1-4AC3-BCCF-5EB3A56EA887@fb.com>
Date: Fri, 22 Sep 2017 19:14:05 +0000
From: Nick Terrell <terrelln@...com>
To: Colin King <colin.king@...onical.com>, Chris Mason <clm@...com>
CC: "kernel-janitors@...r.kernel.org" <kernel-janitors@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] lib: zstd: make const array rtbTable static, reduces
object code size
On 9/22/17, 8:00 AM, "linux-kernel-owner@...r.kernel.org on behalf of Colin King" <linux-kernel-owner@...r.kernel.org on behalf of colin.king@...onical.com> wrote:
> From: Colin Ian King <colin.king@...onical.com>
>
> Don't populate const array rtbTable on the stack, instead make it
> static. Also split overly long line to clean a chechkpach warning.
> Makes the object code smaller by nearly 500 bytes:
>
> Before:
> text data bss dec hex filename
> 13297 104 0 13401 3459 lib/zstd/fse_compress.o
>
> After:
> text data bss dec hex filename
> 12742 160 0 12902 3266 lib/zstd/fse_compress.o
>
> (gcc 6.3.0, x86-64)
>
> Signed-off-by: Colin Ian King <colin.king@...onical.com>
I tested your patch with gcc-7.1 on x86, and benchmarked the speed on
upstream zstd. There isn't a noticeable speed difference, since it isn't a
particularly hot piece of code. Would you be able to submit the same patch
upstream [1], or would you be okay with me porting it back upstream, so it
doesn't get lost on an update?
I didn't expect gcc to leave constant arrays on the stack, that seems
silly. Clang makes it static, but gcc loads it onto the stack, and in 6.3+
it saves the data statically, and then uses vector instructions to load it
onto the stack [2].
Tested-by: Nick Terrell <terrelln@...com>
[1] https://github.com/facebook/zstd
[2] https://godbolt.org/g/fvTcED
Powered by blists - more mailing lists