From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Chapman Flack <chap(at)anastigmatix(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Steele <david(at)pgmasters(dot)net>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Use C99 designated initializers for some structs |
Date: | 2018-08-30 04:55:31 |
Message-ID: | 20180830045531.yt6nvmfvaxihjvip@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2018-08-29 20:35:57 -0400, Chapman Flack wrote:
> On 08/29/18 18:51, Tom Lane wrote:
>
> > As against that, of course, explicitly zeroing fields that you know very
> > well are already zero eats some cycles. I've occasionally wondered if
>
> I haven't checked what a smart C99 compiler actually emits for a
> designated initializer giving a field a compile-time known constant zero.
> Is it sure to eat any more cycles than the same initializer with the field
> unmentioned?
It's unlikely that any compiler worth its salt will emit redundant zero
initializations after a struct initialization (it's dead trivial to
recognize than in any SSA like form, which I think most compilers use
these days, certainly gcc and clang). What it can't optimize away
however is the x = makeNode(SomeType); x->foo = EquivalentToZero;
case. Currently the compiler has no way to know that the memory is zero
initialized (except for the type member, which the compiler can see
being set).
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2018-08-30 04:57:36 | Re: Use C99 designated initializers for some structs |
Previous Message | Yugo Nagata | 2018-08-30 04:48:31 | Fix comments of IndexInfo |