From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 99187385B835 for ; Mon, 30 Mar 2020 16:27:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 99187385B835 Received: from pps.filterd (m0127361.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 02UGCFgI122866; Mon, 30 Mar 2020 12:27:03 -0400 Received: from ppma01dal.us.ibm.com (83.d6.3fa9.ip4.static.sl-reverse.com [169.63.214.131]) by mx0a-001b2d01.pphosted.com with ESMTP id 3021d4qd5m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Mar 2020 12:27:03 -0400 Received: from pps.filterd (ppma01dal.us.ibm.com [127.0.0.1]) by ppma01dal.us.ibm.com (8.16.0.27/8.16.0.27) with SMTP id 02UGOpwG001884; Mon, 30 Mar 2020 16:27:02 GMT Received: from b03cxnp07029.gho.boulder.ibm.com (b03cxnp07029.gho.boulder.ibm.com [9.17.130.16]) by ppma01dal.us.ibm.com with ESMTP id 301x76xk4v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Mar 2020 16:27:02 +0000 Received: from b03ledav003.gho.boulder.ibm.com (b03ledav003.gho.boulder.ibm.com [9.17.130.234]) by b03cxnp07029.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 02UGR0TX7209258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 30 Mar 2020 16:27:00 GMT Received: from b03ledav003.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id AD19C6A058; Mon, 30 Mar 2020 16:27:00 +0000 (GMT) Received: from b03ledav003.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1955F6A04D; Mon, 30 Mar 2020 16:27:00 +0000 (GMT) Received: from [9.160.53.188] (unknown [9.160.53.188]) by b03ledav003.gho.boulder.ibm.com (Postfix) with ESMTP; Mon, 30 Mar 2020 16:26:59 +0000 (GMT) Subject: Re: [PATCH] lower-subreg: PR94123, SVN r273240, causes gcc.target/powerpc/pr87507.c to fail From: Peter Bergner To: Segher Boessenkool , richard.sandiford@arm.com Cc: Gcc-patches , "ian@airs.com" References: <20ee8944-f0bf-cec1-e3d1-5dd5e9c6a4ef@linux.ibm.com> <20200330112612.GQ22482@gate.crashing.org> <6c43dfe0-2dd8-aa95-4ace-62b49657e0aa@linux.ibm.com> Message-ID: <99d2d9f1-ff48-ffc2-f56f-d90ccaac6b84@linux.ibm.com> Date: Mon, 30 Mar 2020 11:26:59 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <6c43dfe0-2dd8-aa95-4ace-62b49657e0aa@linux.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-03-30_06:2020-03-30, 2020-03-30 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 adultscore=0 mlxlogscore=999 priorityscore=1501 lowpriorityscore=0 phishscore=0 mlxscore=0 malwarescore=0 suspectscore=0 bulkscore=0 impostorscore=0 spamscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2003300143 X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Mar 2020 16:27:22 -0000 On 3/30/20 11:23 AM, Peter Bergner wrote: > I kind of agree with Richard above on making it more applicable/symmetric, > but why can't we just remove the HARD_REGISTER_NUM_P() tests altogether? > It's not like lower-subreg is extending hard register lifetime usage than > what is already there in the rtl. We're just decomposing what's already > there into smaller register sized chunks. Is there a problem with that > I'm not aware of? ...or maybe there was an issue when combine used to extend hard register lifetimes (which it doesn't anymore) and the test above was just a workaround? Peter