From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id BFF76385DC1A for ; Wed, 6 Jan 2021 03:12:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org BFF76385DC1A Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 10631BNG101497; Tue, 5 Jan 2021 22:12:12 -0500 Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com with ESMTP id 35w3ud9hvj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 05 Jan 2021 22:12:12 -0500 Received: from m0098420.ppops.net (m0098420.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 106329Ss104483; Tue, 5 Jan 2021 22:12:11 -0500 Received: from ppma01fra.de.ibm.com (46.49.7a9f.ip4.static.sl-reverse.com [159.122.73.70]) by mx0b-001b2d01.pphosted.com with ESMTP id 35w3ud9hv1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 05 Jan 2021 22:12:11 -0500 Received: from pps.filterd (ppma01fra.de.ibm.com [127.0.0.1]) by ppma01fra.de.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 10638YOj023700; Wed, 6 Jan 2021 03:12:10 GMT Received: from b06avi18626390.portsmouth.uk.ibm.com (b06avi18626390.portsmouth.uk.ibm.com [9.149.26.192]) by ppma01fra.de.ibm.com with ESMTP id 35tgf7stgy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 06 Jan 2021 03:12:09 +0000 Received: from d06av25.portsmouth.uk.ibm.com (d06av25.portsmouth.uk.ibm.com [9.149.105.61]) by b06avi18626390.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 1063C4KW33030636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 6 Jan 2021 03:12:04 GMT Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id AFA0B11C04A; Wed, 6 Jan 2021 03:12:07 +0000 (GMT) Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6CC9311C04C; Wed, 6 Jan 2021 03:12:06 +0000 (GMT) Received: from kewenlins-mbp.cn.ibm.com (unknown [9.200.146.88]) by d06av25.portsmouth.uk.ibm.com (Postfix) with ESMTP; Wed, 6 Jan 2021 03:12:06 +0000 (GMT) Subject: Re: [PATCH] ira: Skip some pseudos in move_unallocated_pseudos To: Jeff Law Cc: Bill Schmidt , GCC Patches , Segher Boessenkool References: <6e1b52f1-a038-9725-38af-5e3007023718@linux.ibm.com> <20201222135546.GD2672@gate.crashing.org> <07bd112b-a767-5ba6-720e-3e8873c72d42@linux.ibm.com> <710726bc-8e7e-4799-cd4b-72df1e427759@redhat.com> <83c1fed5-d9aa-5f19-b04c-0ca432ffe183@linux.ibm.com> <23a47ef1-8782-e801-f604-8cd551abc784@redhat.com> From: "Kewen.Lin" Message-ID: <61a54418-bfdc-acc4-9896-cea9e6e84520@linux.ibm.com> Date: Wed, 6 Jan 2021 11:12:04 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <23a47ef1-8782-e801-f604-8cd551abc784@redhat.com> Content-Type: multipart/mixed; boundary="------------32593830A926A6587F9FD3D4" Content-Language: en-US X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-05_09:2021-01-05, 2021-01-05 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 suspectscore=0 adultscore=0 lowpriorityscore=0 mlxlogscore=999 spamscore=0 impostorscore=0 mlxscore=0 malwarescore=0 clxscore=1015 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101060014 X-Spam-Status: No, score=-12.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, 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: Wed, 06 Jan 2021 03:12:14 -0000 This is a multi-part message in MIME format. --------------32593830A926A6587F9FD3D4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit on 2021/1/6 上午2:19, Jeff Law wrote: > > > On 1/4/21 7:36 PM, Kewen.Lin wrote: >> Hi Jeff, >> >> on 2021/1/5 上午7:13, Jeff Law wrote: >>> >>> On 12/22/20 11:40 PM, Kewen.Lin via Gcc-patches wrote: >>>> Hi Segher, >>>> >>>> on 2020/12/22 下午9:55, Segher Boessenkool wrote: >>>>> Hi! >>>>> >>>>> Just a dumb formatting comment: >>>>> >>>>> On Tue, Dec 22, 2020 at 04:05:39PM +0800, Kewen.Lin wrote: >>>>>> This patch is to make move_unallocated_pseudos consistent >>>>>> to what we have in function find_moveable_pseudos, where we >>>>>> record the original pseudo into pseudo_replaced_reg only if >>>>>> validate_change succeeds with newreg. To ensure every >>>>>> unallocated pseudo in move_unallocated_pseudos has expected >>>>>> information, it's better to add a check and skip it if it's >>>>>> unexpected. This avoids possible ICEs in future. >>>>>> >>>>>> btw, I happened to found this in the bootstrapping for one >>>>>> experimental local patch, which is considered as impractical. >>>>>> --- a/gcc/ira.c >>>>>> +++ b/gcc/ira.c >>>>>> @@ -5111,6 +5111,11 @@ move_unallocated_pseudos (void) >>>>>> { >>>>>> int idx = i - first_moveable_pseudo; >>>>>> rtx other_reg = pseudo_replaced_reg[idx]; >>>>>> + /* If there is no appropriate pseudo in pseudo_replaced_reg, it >>>>>> + means validate_change fails for this new pseudo in function >>>>>> + find_moveable_pseudos, then bypass it here.*/ >>>>> Dot space space. >>>> Good catch, thanks! I forgot to reformat after polishing the comments. >>>> Will fix it with other potential comments. >>>> >>>>> The patch sounds fine to me. Hard to tell without seeing the patch that >>>>> exposed the problem (for onlookers like me who do not know this code >>>>> well, anyway ;-) ) >>>> The patch which made this issue exposed looks like: >>>> >>>> +; Like *rotl3_insert_3 but work with nonzero_bits rather than >>>> +; explicit AND. >>>> +(define_insn "*rotl3_insert_8" >>>> + [(set (match_operand:GPR 0 "gpc_reg_operand" "=r") >>>> + (ior:GPR (ashift:GPR (match_operand:GPR 1 "gpc_reg_operand" "r") >>>> + (match_operand:SI 2 "u6bit_cint_operand" "n")) >>>> + (match_operand:GPR 3 "gpc_reg_operand" "0")))] >>>> + "HOST_WIDE_INT_1U << INTVAL (operands[2]) >>>> + > nonzero_bits (operands[3], mode)" >>>> +{ >>>> + if (mode == SImode) >>>> + return "rlwimi %0,%1,%h2,0,31-%h2"; >>>> + else >>>> + return "rldimi %0,%1,%H2,0"; >>>> +} >>>> + [(set_attr "type" "insert")]) >>>> >>>> Some insn matches this pattern in combine, later ira tries to introduce >>>> one new pseudo since it meets the checks in find_moveable_pseudos, but >>>> it fails in the call to validate_change since the nonzero_bits is more >>>> rough and can't satisfy the pattern condition, leaving the unexpected >>>> entry in pseudo_replaced_reg. >>> But what doesn't make any sense to me is pseudo_replaced_reg[] is only >>> set when validation is successful in find_moveable_pseudos.   So I can't >>> see how this patch actually helps the problem you're describing. >>> >> Yeah, pseudo_replaced_reg[] is only set when validation is successful, >> but we bump the max pseudo number in ira_create_new_reg as below >> regardless of whether validation succeeds or not: >> >> rtx newreg = ira_create_new_reg (def_reg); >> if (validate_change (def_insn, DF_REF_REAL_LOC (def), newreg, 0)) >> >> Later in move_unallocated_pseudos, the iterating could cover those >> pseudos which were created but not used due to failed validation. >> >> for (i = first_moveable_pseudo; i < last_moveable_pseudo; i++) >> if (reg_renumber[i] < 0) >> { >> int idx = i - first_moveable_pseudo; >> rtx other_reg = pseudo_replaced_reg[idx]; // (1) >> rtx_insn *def_insn = DF_REF_INSN (DF_REG_DEF_CHAIN (i)); >> /* The use must follow all definitions of OTHER_REG, so we can >> insert the new definition immediately after any of them. */ >> df_ref other_def = DF_REG_DEF_CHAIN (REGNO (other_reg)) >> >> Then we can get the NULL other_reg in (1), also have unexpected df info >> which causes ICE. The patch skips the handlings on those pseudos which >> were intended to be used in validatation INSN but failed to. > I was wondering if it was somehow related to creation of new pseudos.  > The other important tidbit here is we reset last_movable_pseudo near the > end of find_moveable_pseudos. Yeah, the iterating will scan all new pseudos created in find_moveable_pseudos, the problem occurs on those ones that fail to validate. > OK for the trunk with an expanded comment. Thanks! Does the attached new version look good to you? BR, Kewen --------------32593830A926A6587F9FD3D4 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="ira_v2.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ira_v2.diff" ZGlmZiAtLWdpdCBhL2djYy9pcmEuYyBiL2djYy9pcmEuYwppbmRleCA4OWI1ZGY0MDAzZC4u NThjMWVmZTU0YjUgMTAwNjQ0Ci0tLSBhL2djYy9pcmEuYworKysgYi9nY2MvaXJhLmMKQEAg LTUxMTEsNiArNTExMSwxNSBAQCBtb3ZlX3VuYWxsb2NhdGVkX3BzZXVkb3MgKHZvaWQpCiAg ICAgICB7CiAJaW50IGlkeCA9IGkgLSBmaXJzdF9tb3ZlYWJsZV9wc2V1ZG87CiAJcnR4IG90 aGVyX3JlZyA9IHBzZXVkb19yZXBsYWNlZF9yZWdbaWR4XTsKKwkvKiBUaGUgaXRlcmF0aW5n IHJhbmdlIFtmaXJzdF9tb3ZlYWJsZV9wc2V1ZG8sIGxhc3RfbW92ZWFibGVfcHNldWRvKQor CSAgIGNvdmVycyBldmVyeSBuZXcgcHNldWRvIGNyZWF0ZWQgaW4gZmluZF9tb3ZlYWJsZV9w c2V1ZG9zLAorCSAgIHJlZ2FyZGxlc3Mgb2YgdGhlIHZhbGlkYXRpb24gd2l0aCBpdCBpcyBz dWNjZXNzZnVsIG9yIG5vdC4KKwkgICBTbyB3ZSBuZWVkIHRvIHNraXAgdGhlIHBzZXVkb3Mg d2hpY2ggd2VyZSB1c2VkIGluIHRob3NlIGZhaWxlZAorCSAgIHZhbGlkYXRpb25zIHRvIGF2 b2lkIHVuZXhwZWN0ZWQgREYgaW5mbyBhbmQgY29uc2VxdWVudCBJQ0UuCisJICAgV2Ugb25s eSBzZXQgcHNldWRvX3JlcGxhY2VkX3JlZ1tdIHdoZW4gdGhlIHZhbGlkYXRpb24gaXMgc3Vj Y2Vzc2Z1bAorCSAgIGluIGZpbmRfbW92ZWFibGVfcHNldWRvcywgaXQncyBlbm91Z2ggdG8g Y2hlY2sgaXQgaGVyZS4gICovCisJaWYgKCFvdGhlcl9yZWcpCisJICBjb250aW51ZTsKIAly dHhfaW5zbiAqZGVmX2luc24gPSBERl9SRUZfSU5TTiAoREZfUkVHX0RFRl9DSEFJTiAoaSkp OwogCS8qIFRoZSB1c2UgbXVzdCBmb2xsb3cgYWxsIGRlZmluaXRpb25zIG9mIE9USEVSX1JF Rywgc28gd2UgY2FuCiAJICAgaW5zZXJ0IHRoZSBuZXcgZGVmaW5pdGlvbiBpbW1lZGlhdGVs eSBhZnRlciBhbnkgb2YgdGhlbS4gICovCg== --------------32593830A926A6587F9FD3D4--