From: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
To: Joe Perches <joe@perches.com>,
kernelnewbies <kernelnewbies@kernelnewbies.org>,
kernel-janitors <kernel-janitors@vger.kernel.org>,
cocci <cocci@systeme.lip6.fr>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: linux-kernel janitorial RFP: Mark static arrays as const
Date: Wed, 3 Mar 2021 10:41:58 +0100 [thread overview]
Message-ID: <a15e5c4d-a60f-14b9-90e5-4e600771aa9d@prevas.dk> (raw)
In-Reply-To: <053b06c47f08631675c295b5c893b90be4248347.camel@perches.com>
On 02/03/2021 18.42, Joe Perches wrote:
> Here is a possible opportunity to reduce data usage in the kernel.
>
> $ git grep -P -n '^static\s+(?!const|struct)(?:\w+\s+){1,3}\w+\s*\[\s*\]' drivers/ | \
> grep -v __initdata | \
> wc -l
> 3250
>
> Meaning there are ~3000 declarations of arrays with what appears to be
> file static const content that are not marked const.
>
> So there are many static arrays that could be marked const to move the
> compiled object code from data to text minimizing the total amount of
> exposed r/w data.
You can add const if you like, but it will rarely change the generated
code. gcc is already smart enough to take a static array whose contents
are provably never modified within the TU and put it in .rodata:
static int x = 7;
static int y[2] = {13, 19};
static int p(int a, const int *foo)
{
return a + *foo;
}
int q(int a)
{
int b = p(a, &x);
return p(b, &y[b & 1]);
}
$ nm c.o
0000000000000000 T q
0000000000000000 r y
$ size c.o
text data bss dec hex filename
111 0 0 111 6f c.o
So x gets optimized away completely, but y isn't so easy to get rid of -
nevertheless, it's never modified and the address doesn't escape the TU,
so gcc treats is as if it was declared const.
I think you'll see the same if you try adding the const on a few of your
real-life examples. (Of course, the control flow may be so convoluted
that gcc isn't able to infer the constness, so I'm not saying it will
never make a difference - only that you shouldn't expect too much.)
Rasmus
WARNING: multiple messages have this Message-ID (diff)
From: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
To: Joe Perches <joe@perches.com>,
kernelnewbies <kernelnewbies@kernelnewbies.org>,
kernel-janitors <kernel-janitors@vger.kernel.org>,
cocci <cocci@systeme.lip6.fr>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: [Cocci] linux-kernel janitorial RFP: Mark static arrays as const
Date: Wed, 3 Mar 2021 10:41:58 +0100 [thread overview]
Message-ID: <a15e5c4d-a60f-14b9-90e5-4e600771aa9d@prevas.dk> (raw)
In-Reply-To: <053b06c47f08631675c295b5c893b90be4248347.camel@perches.com>
On 02/03/2021 18.42, Joe Perches wrote:
> Here is a possible opportunity to reduce data usage in the kernel.
>
> $ git grep -P -n '^static\s+(?!const|struct)(?:\w+\s+){1,3}\w+\s*\[\s*\]' drivers/ | \
> grep -v __initdata | \
> wc -l
> 3250
>
> Meaning there are ~3000 declarations of arrays with what appears to be
> file static const content that are not marked const.
>
> So there are many static arrays that could be marked const to move the
> compiled object code from data to text minimizing the total amount of
> exposed r/w data.
You can add const if you like, but it will rarely change the generated
code. gcc is already smart enough to take a static array whose contents
are provably never modified within the TU and put it in .rodata:
static int x = 7;
static int y[2] = {13, 19};
static int p(int a, const int *foo)
{
return a + *foo;
}
int q(int a)
{
int b = p(a, &x);
return p(b, &y[b & 1]);
}
$ nm c.o
0000000000000000 T q
0000000000000000 r y
$ size c.o
text data bss dec hex filename
111 0 0 111 6f c.o
So x gets optimized away completely, but y isn't so easy to get rid of -
nevertheless, it's never modified and the address doesn't escape the TU,
so gcc treats is as if it was declared const.
I think you'll see the same if you try adding the const on a few of your
real-life examples. (Of course, the control flow may be so convoluted
that gcc isn't able to infer the constness, so I'm not saying it will
never make a difference - only that you shouldn't expect too much.)
Rasmus
_______________________________________________
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
next prev parent reply other threads:[~2021-03-03 14:12 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-02 17:42 linux-kernel janitorial RFP: Mark static arrays as const Joe Perches
2021-03-02 17:42 ` Joe Perches
2021-03-02 17:42 ` [Cocci] " Joe Perches
2021-03-02 21:41 ` Julia Lawall
2021-03-02 21:41 ` Julia Lawall
2021-03-02 21:41 ` Julia Lawall
2021-03-03 2:47 ` Joe Perches
2021-03-03 2:47 ` Joe Perches
2021-03-03 2:47 ` Joe Perches
2021-03-02 22:18 ` Bernd Petrovitsch
2021-03-02 22:18 ` [Cocci] " Bernd Petrovitsch
2021-03-03 8:36 ` Julia Lawall
2021-03-03 8:36 ` Julia Lawall
2021-03-03 8:36 ` Julia Lawall
2021-03-04 8:34 ` Andy Shevchenko
2021-03-03 9:41 ` Rasmus Villemoes [this message]
2021-03-03 9:41 ` Rasmus Villemoes
2021-03-03 14:51 ` Joe Perches
2021-03-03 14:51 ` Joe Perches
2021-03-03 14:51 ` [Cocci] " Joe Perches
2021-03-07 19:14 ` Julia Lawall
2021-03-07 19:14 ` Julia Lawall
2021-03-07 19:14 ` [Cocci] " Julia Lawall
2021-03-08 5:38 ` Joe Perches
2021-03-08 5:38 ` Joe Perches
2021-03-08 5:38 ` [Cocci] " Joe Perches
2021-03-08 6:54 ` Julia Lawall
2021-03-08 6:54 ` Julia Lawall
2021-03-08 6:54 ` [Cocci] " Julia Lawall
2021-03-03 17:06 ` Mansour Moufid
2021-03-03 17:21 ` Julia Lawall
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a15e5c4d-a60f-14b9-90e5-4e600771aa9d@prevas.dk \
--to=rasmus.villemoes@prevas.dk \
--cc=cocci@systeme.lip6.fr \
--cc=joe@perches.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=kernelnewbies@kernelnewbies.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.