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 392F83836C0F for ; Tue, 5 Jan 2021 02:37:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 392F83836C0F Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 1052Wtjv008553; Mon, 4 Jan 2021 21:37:05 -0500 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 35vcbykx5a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 04 Jan 2021 21:37:05 -0500 Received: from m0098409.ppops.net (m0098409.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 1052aLJK018701; Mon, 4 Jan 2021 21:37:04 -0500 Received: from ppma04fra.de.ibm.com (6a.4a.5195.ip4.static.sl-reverse.com [149.81.74.106]) by mx0a-001b2d01.pphosted.com with ESMTP id 35vcbykx4n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 04 Jan 2021 21:37:04 -0500 Received: from pps.filterd (ppma04fra.de.ibm.com [127.0.0.1]) by ppma04fra.de.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 1052WLrE030584; Tue, 5 Jan 2021 02:37:02 GMT Received: from b06cxnps3074.portsmouth.uk.ibm.com (d06relay09.portsmouth.uk.ibm.com [9.149.109.194]) by ppma04fra.de.ibm.com with ESMTP id 35va37g3ta-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 05 Jan 2021 02:37:01 +0000 Received: from b06wcsmtp001.portsmouth.uk.ibm.com (b06wcsmtp001.portsmouth.uk.ibm.com [9.149.105.160]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 1052axLf37552538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 5 Jan 2021 02:36:59 GMT Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 96896A4060; Tue, 5 Jan 2021 02:36:59 +0000 (GMT) Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id AD5F5A4054; Tue, 5 Jan 2021 02:36:57 +0000 (GMT) Received: from KewenLins-MacBook-Pro.local (unknown [9.197.249.38]) by b06wcsmtp001.portsmouth.uk.ibm.com (Postfix) with ESMTP; Tue, 5 Jan 2021 02:36:57 +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> From: "Kewen.Lin" Message-ID: <83c1fed5-d9aa-5f19-b04c-0ca432ffe183@linux.ibm.com> Date: Tue, 5 Jan 2021 10:36:55 +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: <710726bc-8e7e-4799-cd4b-72df1e427759@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-04_16:2021-01-04, 2021-01-04 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 bulkscore=0 clxscore=1015 phishscore=0 priorityscore=1501 impostorscore=0 mlxscore=0 suspectscore=0 malwarescore=0 spamscore=0 adultscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101050014 X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, 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: Tue, 05 Jan 2021 02:37:07 -0000 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. BR, Kewen