From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id 1C7873858C1F for ; Tue, 19 Sep 2023 16:30:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1C7873858C1F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com Received: from pps.filterd (m0356517.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 38JG8Bu7019984 for ; Tue, 19 Sep 2023 16:30:54 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=date : from : to : subject : message-id : references : mime-version : content-type : in-reply-to; s=pp1; bh=JypJO2Y4hl8dCPwnXbpgL/W4cVKogwpx1YEHxYan21c=; b=gKn3mRYs/eGxFc9EAmmVd+Q4vGylHvVZE4CRcb60duS9ag3S4hLs9ALR2Z57H4iv1jQv 5Zea8XC2qra+AbLE30lgHTFlrUNzD/1R376QKdWKJwPxNV2UK5eNSzuuJH2LkEWRghWh ard2RaqHq5bzv4+cpuN/L3Hx4FF4bdLsLX+Rfv/bPSIzeIWsUxepODiUKZDJfOg9TRPQ vREzeStu3uu18oq5pLbiQ7F+W5BNFm4svprpTKyLBzDYtKQWc0ofVW2CjNdT68CkYTTJ s3OHhSAldrBCfLpezsRhieBviPra3oogDTmgrf3N0f7PE5FzOCrBnkIFoLxjhNfB3r0j GA== Received: from ppma13.dal12v.mail.ibm.com (dd.9e.1632.ip4.static.sl-reverse.com [50.22.158.221]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3t7e8rsnnn-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 19 Sep 2023 16:30:53 +0000 Received: from pps.filterd (ppma13.dal12v.mail.ibm.com [127.0.0.1]) by ppma13.dal12v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 38JF7bEN010375 for ; Tue, 19 Sep 2023 16:06:57 GMT Received: from smtprelay05.fra02v.mail.ibm.com ([9.218.2.225]) by ppma13.dal12v.mail.ibm.com (PPS) with ESMTPS id 3t5rwk5gnj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 19 Sep 2023 16:06:57 +0000 Received: from smtpav05.fra02v.mail.ibm.com (smtpav05.fra02v.mail.ibm.com [10.20.54.104]) by smtprelay05.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 38JG6uxi22610542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 19 Sep 2023 16:06:56 GMT Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EB98B20043 for ; Tue, 19 Sep 2023 16:06:55 +0000 (GMT) Received: from smtpav05.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B733620040 for ; Tue, 19 Sep 2023 16:06:55 +0000 (GMT) Received: from li-819a89cc-2401-11b2-a85c-cca1ce6aa768.ibm.com (unknown [9.171.80.168]) by smtpav05.fra02v.mail.ibm.com (Postfix) with ESMTPS for ; Tue, 19 Sep 2023 16:06:55 +0000 (GMT) Date: Tue, 19 Sep 2023 18:06:55 +0200 From: Stefan Schulze Frielinghaus To: gcc-patches@gcc.gnu.org Subject: Re: PING^5: [PATCH] rtl-optimization/110939 Really fix narrow comparison of memory and constant Message-ID: References: <20230810130402.752335-2-stefansf@linux.ibm.com> <49f59333ae7a3fc1ff6ea03244da3dcf802764e3.camel@xry111.site> <6b775391962e6fd035da3815db32a0465511b08a.camel@xry111.site> <1a4f7fdbde6ff8f4a36426701bc5d68bc855d7e8.camel@xry111.site> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1a4f7fdbde6ff8f4a36426701bc5d68bc855d7e8.camel@xry111.site> X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: l1SDVwj3pJoM_QbRTOACPcS0aN4Vvr37 X-Proofpoint-GUID: l1SDVwj3pJoM_QbRTOACPcS0aN4Vvr37 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.267,Aquarius:18.0.980,Hydra:6.0.601,FMLib:17.11.176.26 definitions=2023-09-19_07,2023-09-19_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 malwarescore=0 mlxlogscore=522 priorityscore=1501 spamscore=0 mlxscore=0 impostorscore=0 clxscore=1015 bulkscore=0 phishscore=0 adultscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2308100000 definitions=main-2309190138 X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Since this patch is sitting in the queue for quite some time and (more importantly?) solves a bootstrap problem let me reiterate: While writing the initial commit 7cdd0860949c6c3232e6cff1d7ca37bb5234074c and the subsequent (potential) fix 41ef5a34161356817807be3a2e51fbdbe575ae85 I was not aware of the fact that the normal form of a CONST_INT, representing an unsigned integer with fewer bits than in HOST_WIDE_INT, is a sign-extended version of the unsigned integer. This invariant is checked in rtl.h where we have at line 2297: case CONST_INT: if (precision < HOST_BITS_PER_WIDE_INT) /* Nonzero BImodes are stored as STORE_FLAG_VALUE, which on many targets is 1 rather than -1. */ gcc_checking_assert (INTVAL (x.first) == sext_hwi (INTVAL (x.first), precision) || (x.second == BImode && INTVAL (x.first) == 1)); This was pretty surprising and frankly speaking unintuitive to me which is why I was skimming further over existing code where I have found this in combine.cc: /* (unsigned) < 0x80000000 is equivalent to >= 0. */ else if (is_a (mode, &int_mode) && GET_MODE_PRECISION (int_mode) - 1 < HOST_BITS_PER_WIDE_INT && ((unsigned HOST_WIDE_INT) const_op == HOST_WIDE_INT_1U << (GET_MODE_PRECISION (int_mode) - 1))) { The expression of the if-statement is a contradiction rendering the then-part unreachable unless you mask out the upper bits of the sign-extended unsigned integer const_op (as proposed in the inlined patch): ((unsigned HOST_WIDE_INT) const_op & GET_MODE_MASK (int_mode)) This is why I got a bit uncertain and hoped to get some feedback whether my intuition is correct or not. Meanwhile I also found a comment in the internals book at "14.7 Constant Expression Types" where we have: "Constants generated for modes with fewer bits than in HOST_WIDE_INT must be sign extended to full width (e.g., with gen_int_mode). [...] Note however that values are neither inherently signed nor inherently unsigned; where necessary, signedness is determined by the rtl operation instead." At least this and the assert statement document that the normal form of a CONST_INT is kind of special w.r.t. unsigned integers. Is there anyone who can shed some light on _why_ such a normal form was chosen? Independent of why such a normal form was chosen, this patch restores the normal form and solves the bootstrap problem for Loongarch. Cheers, Stefan