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 99F313858D20 for ; Mon, 8 Apr 2024 12:30:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 99F313858D20 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 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 99F313858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=148.163.156.1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712579416; cv=none; b=qB+OVIWdqME9aPsKac0WkSWOtM+NZbTR2KMpW4BaQiFqlumlTgTJY2wowLvl4AL46WLcb+QK88bJqGONhlQWPrsQODTNDF6jdmnr6lAwmWIcd3Dx0BSCpuxzjh3ZfGgBrzuNr6JPIMm+CizwMeyFrfntSQ+/kCJ8yq/K0Hh6cbE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712579416; c=relaxed/simple; bh=kyqZ1AyDP6QFuSGZMxiBdQjDCvd6vaRgX56V0oSdz2k=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=vwUFjsy/IvIZ41p94uxeINUIm27n8kri+OKqwwk3KfqF5LkfGGDkRip3PJeRvdbTsdidysVjTNc1WMfAYyXGEkYeb9wp3xIEI7xtB0K0gfbYI5ThX0izawxnKCDS4m3SCBKyO/SiC6oCdjTMXYlocx1AL7IhuBUnCnAOyb2ZgJ8= ARC-Authentication-Results: i=1; server2.sourceware.org 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 438C0phI021530 for ; Mon, 8 Apr 2024 12:30:11 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=p7AKAG/4DPS9fAPUqpGkfkgBA0OLmUhdkU5K/p1Nmk8=; b=Eby5fR3ecWGFsq2XJPR5Z76i48pHL2HKTPy5iPCOnIv9oULgzfZYpDyOcAo3qJnhQfkQ s5sy37aH+QvOK91rTJqBWUQ5ganCP3msSksDFjm9grjAbe15ksPT+n31IrzIGmU1cXuw 5AVTNhLZqOMAb6w0eJFyyU9LM4MMh+WXVVkxsCBEXeLjyXkLTZKmXkm3ChvazyyGRzpO 3w4eZRWcNon3lP8OFGByUQ/NEQhkp1aPXKF5Dvm3Kmk6s7gA2XeET727UdfoaW7H+BDk Rg007ROSpLUqn6fnLm8lQRcIRIfxCy1hegJCjeTwFF6gcvPrf4APOjisM2fb++CsRdcI LQ== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3xceuar6p8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 08 Apr 2024 12:30:11 +0000 Received: from m0356517.ppops.net (m0356517.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 438CUAPa001884 for ; Mon, 8 Apr 2024 12:30:10 GMT Received: from ppma12.dal12v.mail.ibm.com (dc.9e.1632.ip4.static.sl-reverse.com [50.22.158.220]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3xceuar6p4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 08 Apr 2024 12:30:10 +0000 Received: from pps.filterd (ppma12.dal12v.mail.ibm.com [127.0.0.1]) by ppma12.dal12v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 438AtKGw013590; Mon, 8 Apr 2024 12:30:09 GMT Received: from smtprelay03.fra02v.mail.ibm.com ([9.218.2.224]) by ppma12.dal12v.mail.ibm.com (PPS) with ESMTPS id 3xbgqt898n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 08 Apr 2024 12:30:09 +0000 Received: from smtpav06.fra02v.mail.ibm.com (smtpav06.fra02v.mail.ibm.com [10.20.54.105]) by smtprelay03.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 438CU4XN44630496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 8 Apr 2024 12:30:06 GMT Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id EAAAB20049; Mon, 8 Apr 2024 12:30:03 +0000 (GMT) Received: from smtpav06.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D545620040; Mon, 8 Apr 2024 12:30:03 +0000 (GMT) Received: from [9.152.224.146] (unknown [9.152.224.146]) by smtpav06.fra02v.mail.ibm.com (Postfix) with ESMTP; Mon, 8 Apr 2024 12:30:03 +0000 (GMT) Message-ID: <6cab44bf-89c8-480b-9ddc-2bf8ff0b9a54@linux.ibm.com> Date: Mon, 8 Apr 2024 14:30:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] s390: Fix s390_const_int_pool_entry_p and movdi peephole2 [PR114605] To: Ilya Leoshkevich , Jakub Jelinek Cc: gcc-patches@gcc.gnu.org References: Content-Language: en-US From: Andreas Krebbel In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: eyctGs7n679zdhzmXWwXVg3UM7XJB4fA X-Proofpoint-ORIG-GUID: I_8IeWFoTpkkc2GHq1gXTN5CLF69iuFL X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-04-08_11,2024-04-05_02,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 clxscore=1015 lowpriorityscore=0 mlxlogscore=999 mlxscore=0 spamscore=0 priorityscore=1501 suspectscore=0 adultscore=0 phishscore=0 bulkscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2404010000 definitions=main-2404080096 X-Spam-Status: No, score=-4.6 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: On 4/8/24 13:43, Ilya Leoshkevich wrote: > On Sat, 2024-04-06 at 18:58 +0200, Jakub Jelinek wrote: >> Hi! >> >> The following testcase is miscompiled, because we have initially >> a movti which loads the 0x3f8000003f800000ULL TImode constant >> from constant pool.  Later on we split it into a pair of DImode >> loads.  Now, for the first load (why just that?, though not stage4 >> material) we trigger the peephole2 which uses >> s390_const_int_pool_entry_p. >> That function doesn't check at all the constant pool mode though, >> sees >> the constant pool at that address has a CONST_INT value and just >> assumes >> that is the value to return, which is especially wrong for big- >> endian, >> if it is a DImode load from offset 0, it should be loading 0 rather >> than >> 0x3f8000003f800000ULL. >> The following patch adds checks if we are extracing a MODE_INT mode, >> if the constant pool has MODE_INT mode as well, punts if constant >> pool >> has smaller mode size than the extraction one (then it would be UB), >> if it has the same mode as before keeps using what it did before, >> if constant pool has a larger mode than the one being extracted, uses >> simplify_subreg.  I'd have used avoid_constant_pool_reference >> instead which can handle also offsets into the constant pool >> constants, >> but it can't handle UNSPEC_LTREF. >> >> Another thing is that once that is fixed, we ICE when we extract >> constant >> like 0, ior insn predicate require non-0 constant.  So, the patch >> also >> fixes the peephole2 so that if either 32-bit half is zero, it uses a >> mere >> load of the constant into register rather than a pair of such load >> and ior. >> >> Bootstrapped/regtested on s390x-linux, ok for trunk? > > Hi Jakub, thanks for the patch, it looks good to me. > Since I'm not a maintainer, we need to wait for Andreas' opinion. Ok. Thank you very much Jakub for fixing this! Andreas > >> >> 2024-04-06  Jakub Jelinek  >> >> PR target/114605 >> * config/s390/s390.cc (s390_const_int_pool_entry_p): Punt >> if mem doesn't have MODE_INT mode, or pool constant doesn't >> have MODE_INT mode, or if pool constant mode is smaller than >> mem mode.  If mem mode is different from pool constant mode, >> try to simplify subreg.  If that doesn't work, punt, if it >> does, use the simplified constant instead of the constant >> pool >> constant. >> * config/s390/s390.md (movdi from const pool peephole): If >> either low or high 32-bit part is zero, just emit move insn >> instead of move + ior. >> >> * gcc.dg/pr114605.c: New test.