Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s9pDl-005NCY-6O for pgsql-general@arkaria.postgresql.org; Wed, 22 May 2024 16:53:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1s9pDl-001OjM-9d for pgsql-general@arkaria.postgresql.org; Wed, 22 May 2024 16:53:45 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s9pDk-001OjD-VD for pgsql-general@lists.postgresql.org; Wed, 22 May 2024 16:53:44 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s9pDi-000EP7-00 for pgsql-general@postgresql.org; Wed, 22 May 2024 16:53:44 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 44MGrXtT4162325; Wed, 22 May 2024 12:53:34 -0400 From: Tom Lane To: Daniel Gustafsson cc: XChy , pgsql-general@postgresql.org Subject: Re: Missed compiler optimization issue in function select_rtable_names_for_explain In-reply-to: <23848714-3662-428E-8E6D-5986D87491D6@yesql.se> References: <05C4ADF5-5E8C-49EC-8E0A-804BB946F1C7@yesql.se> <23848714-3662-428E-8E6D-5986D87491D6@yesql.se> Comments: In-reply-to Daniel Gustafsson message dated "Wed, 22 May 2024 12:55:48 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4162323.1716396813.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Wed, 22 May 2024 12:53:33 -0400 Message-ID: <4162324.1716396813@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Daniel Gustafsson writes: > They are known to be zero, but that's not entirely equivalent though is = it? > NIL is defined as ((List *) NULL) and NULL is typically defined as ((voi= d *) > 0), so sizeof(0) would be the size of an int and sizeof(NULL) would be t= he size > of a void pointer. There are other places where we assume that a memset-to-zero will produce null pointers, so I don't think that that objection has a lot of force. My real answer is that this is our coding style and we are not going to change it: our normal convention is to initialize struct fields in declaration order, and that's what we're doing here. If some particular version of some particular compiler fails to make an entirely-negligible optimization in consequence, that is not something we are going to care about. Maybe we would care if the missed optimization were a serious performance loss in a very hot code path. But this is neither. I'd also say that this is pretty clearly a compiler bug. If it'd normally optimize away a null-pointer-store following a memset-to-zero, but does not in memset(&dpns, 0, sizeof(dpns)); dpns.rtable =3D rtable; dpns.subplans =3D NIL; dpns.ctes =3D NIL; dpns.appendrels =3D NULL; that would seem to indicate that the optimizer doesn't really understand that dpns.rtable is a distinct field from the others. How is that our problem? (I kind of wonder if what's actually blocking the optimization is the casts inside the NIL macros. Still not our problem.) regards, tom lane