Re: Missed compiler optimization issue in function select_rtable_names_for_explain

From: XChy <xxs_chy(at)outlook(dot)com>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Missed compiler optimization issue in function select_rtable_names_for_explain
Date: 2024-05-22 13:41:08
Message-ID: OS0P286MB01631DCDCB5E5BAE8CB2AFE682EB2@OS0P286MB0163.JPNP286.PROD.OUTLOOK.COM
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


在 2024/5/22 18:55, Daniel Gustafsson 写道:
>> I mean that the stores with value "0" after the memset are dead:
>> ```
>> dpns.subplans = NIL;
>> dpns.ctes = NIL;
>> dpns.appendrels = NULL;
>> ```
>> since the memset has written zeroes to the object "dpns", and these members are known to be zero.
> 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 ((void *)
> 0), so sizeof(0) would be the size of an int and sizeof(NULL) would be the size
> of a void pointer.

The type or size doesn't matter here. At IR or assembly level, they are
all zeroes.

My main point is that "dpns.xxx" are filled with zeroes by the memset
firstly, and overwriting them with zeroes in the following stores is
redundant. LLVM cannot remove the redundant overwrites due to the
initialization order. If we adjust the order of the initialization of
"dpns.xxx", the compiler can remove such stores.

Does my explanation make sense to you?

Best regards, Hongyu.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Greg Sabino Mullane 2024-05-22 14:14:25 Re: Finding "most recent" using daterange
Previous Message Alvaro Herrera 2024-05-22 11:00:12 Re: Missed compiler optimization issue in function select_rtable_names_for_explain