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 C459638515D4; Thu, 17 Jun 2021 02:36:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C459638515D4 Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 15H2XoXH081545; Wed, 16 Jun 2021 22:36:24 -0400 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 397vj5sevf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 16 Jun 2021 22:36:24 -0400 Received: from m0098410.ppops.net (m0098410.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 15H2aOah090756; Wed, 16 Jun 2021 22:36:24 -0400 Received: from ppma05wdc.us.ibm.com (1b.90.2fa9.ip4.static.sl-reverse.com [169.47.144.27]) by mx0a-001b2d01.pphosted.com with ESMTP id 397vj5sev4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 16 Jun 2021 22:36:24 -0400 Received: from pps.filterd (ppma05wdc.us.ibm.com [127.0.0.1]) by ppma05wdc.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 15H2XMfD011160; Thu, 17 Jun 2021 02:36:22 GMT Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by ppma05wdc.us.ibm.com with ESMTP id 3954gkgm2k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 17 Jun 2021 02:36:22 +0000 Received: from b03ledav003.gho.boulder.ibm.com (b03ledav003.gho.boulder.ibm.com [9.17.130.234]) by b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 15H2aMN127132186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 17 Jun 2021 02:36:22 GMT Received: from b03ledav003.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E895D6A05D; Thu, 17 Jun 2021 02:36:21 +0000 (GMT) Received: from b03ledav003.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6BFF06A04D; Thu, 17 Jun 2021 02:36:21 +0000 (GMT) Received: from ltc.linux.ibm.com (unknown [9.10.229.42]) by b03ledav003.gho.boulder.ibm.com (Postfix) with ESMTP; Thu, 17 Jun 2021 02:36:21 +0000 (GMT) Content-Type: text/plain; charset=UTF-8; format=flowed Date: Thu, 17 Jun 2021 10:36:21 +0800 From: guojiufu To: Jan Hubicka Cc: Jan Hubicka , Richard Biener , segher@kernel.crashing.org, gcc-patches@gcc.gnu.org, Jeff Law , wschmidt@linux.ibm.com, Jan Hubicka , dje.gcc@gmail.com, Gcc-patches Subject: Re: Ping: [PATCH 1/2] correct BB frequencies after loop changed Message-ID: <172b2a5c210238a6d3e02bc7cd17d3aa@imap.linux.ibm.com> X-Sender: guojiufu@linux.ibm.com User-Agent: Roundcube Webmail/1.1.12 X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: cA4jn2SDCzL71KliE_IUWbID2dQYXN-7 X-Proofpoint-GUID: r5qsED0mmZ57J2fsiLfT7R5xx1kLgvIp Content-Transfer-Encoding: 8bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-06-17_01:2021-06-15, 2021-06-17 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 mlxscore=0 suspectscore=0 bulkscore=0 phishscore=0 adultscore=0 clxscore=1015 impostorscore=0 spamscore=0 priorityscore=1501 malwarescore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2106170014 X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_MSPIKE_H3, 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: Thu, 17 Jun 2021 02:36:27 -0000 On 2021-06-15 12:57, guojiufu via Gcc-patches wrote: > On 2021-06-14 17:16, Jan Hubicka wrote: >>> >>> >>> On 5/6/2021 8:36 PM, guojiufu via Gcc-patches wrote: >>> > Gentle ping. >>> > >>> > Original message: >>> > https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555871.html >>> I think you need a more aggressive ping  :-) >>> >>> OK for the trunk.  Sorry for the long delay.  I kept hoping someone >>> else >>> would step in and look at it. >> Sorry, the patch was on my todo list to think through for a while :( >> It seems to me that both old and new code needs bit more work. First >> the exit loop frequency is set to >> >> prob = profile_probability::always ().apply_scale (1, new_est_niter + >> 1); >> >> which is only correct if the estimated number of iterations is >> accurate. >> If we do not have profile feedback and trip count is not known >> precisely >> in most cases it won't be. We estimate loops to iterate about 3 times >> and then niter_for_unrolled_loop will apply the capping to 5 >> iterations >> that is completely arbitrary. >> >> Forcing exit probability to precise may then disable futher loop >> optimizations since after the change we will think we know the loop >> iterates 5 times and thus it is not worthy for loop opt (which is >> quite >> oposite with the fact that we are just unrolling it thinking it is >> hot). > > Thanks, understand your concern, both new and old code are assuming the > the number of iterations is accurate. > Maybe we could add code to reset exit probability for the case > where "!count_in.reliable_p ()". > >> >> Old code does >> 1) scale body down so only one iteration is done >> 2) set exit edge probability to be 1/(new_est_iter+1) >> precisely >> 3) scale up accoring to the 1/new_nonexit_prob >> which would be correct if the nonexit probability was updated to >> 1-exit_probability but that does not seem to happen. >> >> New code does > Yes, this is intended: we know that the enter-count should be > equal to the exit-count of one loop, and then the > "loop-body-count * exit-probability = exit-count". > Also, the entry count of the loop would not be changed before and after > one optimization (or slightly change,e.g. peeling count). > > Based on this, we could adjust the loop body count according to > exit-count (or say enter-count) and exit-probability, when the > exit-probability is easy to estimate. > >> 1) give up when there are multiple exits. >> I wonder how common this is - we do outer loop vectorizaiton > > The computation in the new code is based on a single exit. This is > also a requirement of old code, and it would be true when run to here. To support multiple exits, I'm thinking about the way to calculate the count/probability for each basic_block and each exit edge. While it seems the count/prob may not scale up on the same ratio. This is another reason I give up these cases with multi-exits. Any suggestions about supporting these cases? BR, Jiufu Guo > >> 2) adjust loop body count according to the exit >> 3) updat profile of BB after the exit edge. >> > > >> Why do you need: >> + if (current_ir_type () != IR_GIMPLE) >> + update_br_prob_note (exit->src); >> >> It is tree_transform_and_unroll_loop, so I think we should always have >> IR_GIMPLE? > > These two lines are added to "recompute_loop_frequencies" which can be > used > in rtl, like the second patch of this: > https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555872.html > Oh, maybe these two lines code would be put to > tree_transform_and_unroll_loop > instead of common code recompute_loop_frequencies. > > Thanks a lot for the review in your busy time! > > BR. > Jiufu Guo >> >> Honza >>> >>> jeff