All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.