Re: plenty code is confused about function level static

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: plenty code is confused about function level static
Date: 2024-04-18 07:00:59
Message-ID: fa65be0e-b3f5-4977-bfbc-30f07137c307@iki.fi
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 18/04/2024 00:39, Andres Freund wrote:
> Hi,
>
> We have a fair amount of code that uses non-constant function level static
> variables for read-only data. Which makes little sense - it prevents the
> compiler from understanding
>
> a) that the data is read only and can thus be put into a segment that's shared
> between all invocations of the program
> b) the data will be the same on every invocation, and thus from optimizing
> based on that.
>
> The most common example of this is that all our binaries use
> static struct option long_options[] = { ... };
> which prevents long_options from being put into read-only memory.
>
>
> Is there some reason we went for this pattern in a fair number of places? I
> assume it's mostly copy-pasta, but...
>
>
> In practice it often is useful to use 'static const' instead of just
> 'const'. At least gcc otherwise soemtimes fills the data on the stack, instead
> of having a read-only data member that's already initialized. I'm not sure
> why, tbh.

Weird. I guess it can be faster if you assume the data in the read-only
section might not be in cache, but the few instructions needed to fill
the data locally in stack are.

> Attached are fixes for struct option and a few more occurrences I've found
> with a bit of grepping.

+1

--
Heikki Linnakangas
Neon (https://neon.tech)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2024-04-18 07:02:18 Re: Support a wildcard in backtrace_functions
Previous Message Ajin Cherian 2024-04-18 06:26:22 Re: Slow catchup of 2PC (twophase) transactions on replica in LR