Feedback-ID: ia2694551:Fastmail
Date: Wed, 22 May 2024 13:00:12 +0200
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: XChy <xxs_chy@outlook.com>
Cc: pgsql-general@postgresql.org
Subject: Re: Missed compiler optimization issue in function
 select_rtable_names_for_explain
Message-ID: <202405221100.fy66dsew2f52@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <OS0P286MB016392E0B2017DDB6709A11C82EB2@OS0P286MB0163.JPNP286.PROD.OUTLOOK.COM>
Archived-At: <https://www.postgresql.org/message-id/202405221100.fy66dsew2f52%40alvherre.pgsql>
Precedence: bulk

On 2024-May-22, XChy wrote:

> Hi everyone,
> 
> I'm a compiler developer working on detecting missed optimization in
> real-world applications. Recently, we found that LLVM missed a dead store
> elimination optimization in the PostgreSQL code <https://github.com/postgres/postgres/blob/c37267162e889fe783786b9e28d1b65b82365a00/src/backend/utils/adt/ruleutils.c#L3794> (https://github.com/postgres/postgres/blob/master/src/backend/utils/adt/ruleutils.c#L3794)
> in the master branch.

I think if we want to improve how this code is seen by the compiler by
modifying it, we should just remove the NULL/NIL assignments.  It's a
pretty arbitrary (and rather small) subset of fields being initialized,
fields which very obviously have been zeroed by memset already, so I
don't see any value in the explicit assignments.

The criteria may be different in cases where some struct has all of its
members initialized to something, because at least you can use that kind
of thing to find places you need to modify when adding new struct
members.  Not so in select_rtable_names_for_explain.

-- 
Álvaro Herrera               48°01'N 7°57'E  —  https://www.EnterpriseDB.com/
"I can see support will not be a problem.  10 out of 10."    (Simon Wittber)
      (http://archives.postgresql.org/pgsql-general/2004-12/msg00159.php)