Content-Type: multipart/alternative;
 boundary="------------uUWYYVbyzJ3yEeiYpaHWG0S0"
Message-ID:
 <OS0P286MB01631DCDCB5E5BAE8CB2AFE682EB2@OS0P286MB0163.JPNP286.PROD.OUTLOOK.COM>
Date: Wed, 22 May 2024 21:41:08 +0800
User-Agent: Mozilla Thunderbird
Subject: Re: Missed compiler optimization issue in function
 select_rtable_names_for_explain
To: Daniel Gustafsson <daniel@yesql.se>
References: <OS0P286MB016392E0B2017DDB6709A11C82EB2@OS0P286MB0163.JPNP286.PROD.OUTLOOK.COM>
 <05C4ADF5-5E8C-49EC-8E0A-804BB946F1C7@yesql.se>
 <OS0P286MB01632009BF9AA52386BA9E4D82EB2@OS0P286MB0163.JPNP286.PROD.OUTLOOK.COM>
 <23848714-3662-428E-8E6D-5986D87491D6@yesql.se>
Content-Language: en-US
Cc: pgsql-general@postgresql.org
From: XChy <xxs_chy@outlook.com>
In-Reply-To: <23848714-3662-428E-8E6D-5986D87491D6@yesql.se>
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: OS0P286MB0163:EE_|TY3P286MB3031:EE_
X-MS-Office365-Filtering-Correlation-Id: 7cb1dab2-7921-453a-7c7e-08dc7a64d8b3
X-Microsoft-Antispam: BCL:0;ARA:14566002|461199019|3412199016|440099019;
X-Microsoft-Antispam-Message-Info:
	IkNpgkYbMicxE2T4JjiQy57o+xneyMkrtdajE/m3ZyW+jNLjwPmGYeSBVXxNcUBqmDTHzQhYqZcz1HDybDCzfVtzGmUCPcJ3nIE2fxEUpMfKB79tjyf/BNz4bfOyI0c0g0+JBYBzQpMiVOi3YgC1PKqjqjnxsHaNnakCpSXb1hmLc8EO/WVKP0UW6pb5kGVunx6wgb17JZLDZ80+Y/HL2ZpRWvAIoZ7XA0ixDFQdLJvMU2p9ay4ySsKGOBcUL10QntczCPRde0EPn/TQUBCRDxxFVFUVmnXsRdktg7nIqu1XEurtbiaRMv4vPwb/3oaWjQSD7IIPDTaJqjc0QIZPxyZijfbmQ425UKz5k6d186udsXF6zNPERWRhx4oxn/ewbMTeecY8Q158lWi+nuzFhdOi3bxMsrahkzwawoEv+h+nsDLeJmJTCKYennrEaxuvSclLUw6T1FZfqG2CQ47OGdLPHBZ81+mSMub3wlpzrvizzx8m4ok9ktJ0L12JHKbmulAru6ItZ+tVRi3Td2Q+gIj+kLopkdncfWnoqsDbRlGhSqeOBJm8nzXn32eJ+21P
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?utf-8?B?aHRSZmVQWjJiY0ZEdVA2aHljajM1azM0WVdtM1ZrMVB6dy8xbmlTR2dxTVVp?=
 =?utf-8?B?NXVvUk5qbXdaa05oOEJtQkZPRjNyVWRnMXNpWWJoZ29RTTU3NzlqSWQ5QUt4?=
 =?utf-8?B?SFRBMkU5SUJybEg4cUVwenUvQWtOKzBBNmt5ZmJEMWVjWXAvWGVsZVEwTHpx?=
 =?utf-8?B?am9oVW56YnZaaFVBMWxWdHVEb2RVSzNXaTdmSnRRbUZyVHhId2RQNU9mbTBQ?=
 =?utf-8?B?MncybmFNNGcxL01ydkppOTFjSmcra0g2MzJGOVEyTnFXdWUrQ1g1YUQxRkc3?=
 =?utf-8?B?RVJrUlRiODI2TU9iM3FzY0pBNll1anpWZ3FaWk1SeXVMajM5Q2hhQng5MlZM?=
 =?utf-8?B?OG95NGcyVUdVZUV1MVBvVG5oakhMemI5Z2FTMFQ4MTdiQWhyc2Eybm5kV05S?=
 =?utf-8?B?YlhhaWVDVi9UaXBBd3BYTGxVdVhQT096S3lZdkNoV0RZUzBjRnVMWDVMdUFq?=
 =?utf-8?B?bmZ3S2VYNElQeUZNWVdSRTNMRVU4VVVRYWVjUGdYU1JrRFBaYTlyMVczU01K?=
 =?utf-8?B?aXcyU1hUc0ZLREdKQXNLOUhKcENyTGw4VG1oa24xY0dHWnN5RVRGOWdPNllp?=
 =?utf-8?B?bkZLZE1XMVZtL3hXVXNoQ3RTVCsxQzBZRUZoSHl3clVBcVlUODRyNUUwQWlQ?=
 =?utf-8?B?cnZyWjRabUJ6YkRpQjBNZmt1ZVNEeExDMlVPL0NMUU9tc01tb08wUVNGRndh?=
 =?utf-8?B?UWlhaFpSTEdLZXpKY2dTSC91bGZOMmRxYmIvL1VweGxvMFpQSDk4NVkxVDE5?=
 =?utf-8?B?QXpUTFc5Q2RUTVliUnUwcmg1a1RCYm91MlJDWTBmdjJjVXN2eFB5MmVwVnhI?=
 =?utf-8?B?bFdMbmt2SGJIRFZ3UEtQQktXUGVDQURhRkdMVnM3YTFhTTg5dHNTRmR4ZkZW?=
 =?utf-8?B?QVhSelZVYUZycTdOQXNuTzNkQTRFRE82WDVqWFhqNUxyQXdOc2FhQWtVTVJj?=
 =?utf-8?B?M3ZTNG5ISlRQbWtqZHZuMUJvbkVCeUJ3ZVhXdFFyUHlKYjg5YlU1WDg4SnRP?=
 =?utf-8?B?aS81bkRRMkkxekJEazd6amh2WFVYVS9mUjhNcHhGdjZSSTVaenF1QTRKVjNl?=
 =?utf-8?B?UVVRS0dNNjVnS3ArRElEMDhzQjZrZVVlWUtXbEgyNVpRakNOb0pnVi90bEJp?=
 =?utf-8?B?TWFaTVh1TnFobFFUY3M4ZnVBOUZlK0NTVlpiUVViaElTQk5CZUJnUmRxcE5O?=
 =?utf-8?B?S2ZxSVVNbVcxRUIwLzNZQ1ZFeS9mTFlnRldsV3NnekdNNmlMOGpudXliNVhZ?=
 =?utf-8?B?UVJGNVlMZWJNSm52U2JMd3VkZERBWm8xcGJ3ckZNQzNmZXV1b216RFgrL0ls?=
 =?utf-8?B?UnJ5dlhLc29TUUlsT1lSUld3NThVK3NGV1M0SzFwZTBwKzlXKzNxYmJqOW55?=
 =?utf-8?B?ZDcyV29qVXY0MTZBdVZmZDh1Z1NSb0xUbld1eDc5cVBLcU5WR1ZtTjBTang4?=
 =?utf-8?B?S2ZTZnZvWGRQblpncXg5a21LTEZETlRWSHJrNjdzQlpoQlR1M2picE05SmtN?=
 =?utf-8?B?c2J3aGY2Q25YLzNqelRsajlRSkpjQzR2K3dnSVJvNURtaUZSVWpMOEdBNDhu?=
 =?utf-8?B?c2cyVGRrejhSY1RpT1ZwWngwbzVoRGtzUkZqTit5bU95UDRtdnhyaHIzYjIz?=
 =?utf-8?Q?4k+Lp5qVNOQeGYhfUvfDVYh/IxNqwppyhxFn0o4e+Ai8=3D?=
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7cb1dab2-7921-453a-7c7e-08dc7a64d8b3
X-MS-Exchange-CrossTenant-AuthSource: OS0P286MB0163.JPNP286.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 May 2024 13:41:13.3610
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY3P286MB3031
List-Id: <pgsql-general.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-general@lists.postgresql.org>
List-Owner: <mailto:pgsql-general-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-general>
Archived-At: <https://www.postgresql.org/message-id/OS0P286MB01631DCDCB5E5BAE8CB2AFE682EB2%40OS0P286MB0163.JPNP286.PROD.OUTLOOK.COM>
Precedence: bulk

--------------uUWYYVbyzJ3yEeiYpaHWG0S0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


在 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.

--------------uUWYYVbyzJ3yEeiYpaHWG0S0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">在 2024/5/22 18:55, Daniel Gustafsson
      写道:<br>
    </div>
    <blockquote type="cite" cite="mid:23848714-3662-428E-8E6D-5986D87491D6@yesql.se"><span style="white-space: pre-wrap">
</span><span style="white-space: pre-wrap">
</span>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">I mean that the stores with value &quot;0&quot; after the memset are dead:
``` 
    dpns.subplans = NIL;
    dpns.ctes = NIL;
    dpns.appendrels = NULL;
```
since the memset has written zeroes to the object &quot;dpns&quot;, and these members are known to be zero.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
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.
</pre>
    </blockquote>
    <p>The type or size doesn't matter here. At IR or assembly level,
      they are all zeroes.&nbsp;</p>
    <p>My main point is that &quot;dpns.xxx&quot; 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 &quot;dpns.xxx&quot;, the compiler can remove such stores.</p>
    <p>Does my explanation make sense to you?<br>
    </p>
    <p>Best regards, Hongyu.<br>
    </p>
  </body>
</html>

--------------uUWYYVbyzJ3yEeiYpaHWG0S0--