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 2EFEA3858295 for ; Wed, 14 Feb 2024 19:45:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2EFEA3858295 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 2EFEA3858295 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=1707939903; cv=none; b=Kp2QQJ0S9qSyQTaZUwnpzZFbRpOsv9wrzkeyhjpjM1UnOmi2qdPtwVlrg0HLbB7vBHYpWYTl5vYZCGzPWlPaZGqx+idenNThuMFHD7RFDCpwm95atN2verchHclJr8dKUl0nuwW3wknKLEHp1p1PxlOrP/JJaH8KB9MDxxHpj8k= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707939903; c=relaxed/simple; bh=lw7Sk9hFiW7Gr/WDcTlsCb6Iw+MnOjqbz01iffqTFAA=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=Ph2gf1N0OiLPH2toLr0AS/9Gku+iu10uT1RGeVaCGGwxCO7yyX7MjUurm8jTNHMw3jBlYpVMi5fPMbqHLue0M2xUR+/oVcUCkiiM8H4u1bGXCsaX0yRm68S/9P4qZ47pjmBiLPGFDnpGBtI653st1YtDCPIS35gd2L3+TIW7lww= 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 41EJCjNC007269; Wed, 14 Feb 2024 19:44:57 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : to : references : from : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=Tj2rX/vUeusGivM1PkZQmAzJTyLshojjk2lw4COuzE0=; b=bv5PtUh5lqHajDFDTPrDxcRBA+4KXYOv1AkFE5kc9rPeoalVuB/22OfrqmibsTJ71N5L RoaT7f+4TAyRIIpBDQHcAzIN5BFUMLi2Ar+vVaED9pQ0ktWOBIewiJo7c7Q25RFV0fNb IzIlNXDSRAKdKoKZDD2C2dQeaAmogh4xsW7dq7PY1D5bnwSikXA2sEo7IfFQiPct7VY/ VZ1ZrmMhYndEqaj73SQYxNGYuMBRZifMN8bM9ULGgE28sTDypCqIJy6WZXS6e+a3D9og 9oll7yrT1KYQD+ZndkOXKe9ENu3F40tvawq0rCJ9VGtmvzF32MugxwyeEXUtEZDCCbls 9g== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3w93fm8p57-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Feb 2024 19:44:57 +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 41EJigks007223; Wed, 14 Feb 2024 19:44:56 GMT Received: from ppma21.wdc07v.mail.ibm.com (5b.69.3da9.ip4.static.sl-reverse.com [169.61.105.91]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3w93fm8p4y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Feb 2024 19:44:56 +0000 Received: from pps.filterd (ppma21.wdc07v.mail.ibm.com [127.0.0.1]) by ppma21.wdc07v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 41EIdu6f024888; Wed, 14 Feb 2024 19:44:55 GMT Received: from smtprelay04.wdc07v.mail.ibm.com ([172.16.1.71]) by ppma21.wdc07v.mail.ibm.com (PPS) with ESMTPS id 3w6mfpg33g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Feb 2024 19:44:55 +0000 Received: from smtpav05.dal12v.mail.ibm.com (smtpav05.dal12v.mail.ibm.com [10.241.53.104]) by smtprelay04.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 41EJiqxl37290486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 14 Feb 2024 19:44:54 GMT Received: from smtpav05.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5A7D258056; Wed, 14 Feb 2024 19:44:52 +0000 (GMT) Received: from smtpav05.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0CEF25806B; Wed, 14 Feb 2024 19:44:49 +0000 (GMT) Received: from [9.43.109.182] (unknown [9.43.109.182]) by smtpav05.dal12v.mail.ibm.com (Postfix) with ESMTP; Wed, 14 Feb 2024 19:44:48 +0000 (GMT) Message-ID: <472e5246-c205-4e3c-ad3a-4f8f0427138b@linux.ibm.com> Date: Thu, 15 Feb 2024 01:14:47 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH V2] rs6000: New pass for replacement of adjacent loads fusion (lxv). Content-Language: en-US To: Alex Coplan , "Kewen.Lin" , Segher Boessenkool , David Edelsohn , Peter Bergner , Michael Meissner , gcc-patches , richard.sandiford@arm.com References: <1043f073-45b7-4e8d-8dac-bba0aa3269c4@linux.ibm.com> From: Ajit Agarwal In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: gwR8LmD39bMiJboYr6WYZ8vLZzmuw6pK X-Proofpoint-GUID: j0kkp3S-LrnmuQ_1F6CpLbrfAxfTCAPU 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-02-14_12,2024-02-14_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 spamscore=0 phishscore=0 impostorscore=0 malwarescore=0 suspectscore=0 lowpriorityscore=0 adultscore=0 mlxscore=0 priorityscore=1501 mlxlogscore=896 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000 definitions=main-2402140154 X-Spam-Status: No, score=-12.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,GIT_PATCH_0,KAM_MANYTO,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: Hello Richard: On 14/02/24 10:45 pm, Richard Sandiford wrote: > Ajit Agarwal writes: >>>> diff --git a/gcc/emit-rtl.cc b/gcc/emit-rtl.cc >>>> index 1856fa4884f..ffc47a6eaa0 100644 >>>> --- a/gcc/emit-rtl.cc >>>> +++ b/gcc/emit-rtl.cc >>>> @@ -921,7 +921,7 @@ validate_subreg (machine_mode omode, machine_mode imode, >>>> return false; >>>> >>>> /* The subreg offset cannot be outside the inner object. */ >>>> - if (maybe_ge (offset, isize)) >>>> + if (maybe_gt (offset, isize)) >>>> return false; >>> >>> Can you explain why this change is needed? >>> >> >> This is required in rs6000 target where we generate the subreg >> with offset 16 from OO mode (256 bit) to 128 bit vector modes. >> Otherwise it segfaults. > > Could you go into more detail? Why does that subreg lead to a segfault? > > In itself, a 16-byte subreg at byte offset 16 into a 32-byte pair is pretty > standard. AArch64 uses this too for its vector load/store pairs (and for > structure pairs more generally). > If we want to create subreg V16QI (reg OO R) 16) imode is V16QI (isize = 16) and offset is 16. maybe_ge (offset, isize) return true and validate_subreg returns false; Hence above subreg is not generated and we generate incorrect code. Thats why I have modified to maybe_gt (offset, isize). Thanks & Regards Ajit > Thanks, > Richard