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 E7034397C86B for ; Fri, 2 Jul 2021 09:05:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E7034397C86B Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 16294295148881; Fri, 2 Jul 2021 05:05:44 -0400 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 39hqx1u3e9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 02 Jul 2021 05:05:44 -0400 Received: from m0098409.ppops.net (m0098409.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 16294bnR150871; Fri, 2 Jul 2021 05:05:43 -0400 Received: from ppma06ams.nl.ibm.com (66.31.33a9.ip4.static.sl-reverse.com [169.51.49.102]) by mx0a-001b2d01.pphosted.com with ESMTP id 39hqx1u3cm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 02 Jul 2021 05:05:43 -0400 Received: from pps.filterd (ppma06ams.nl.ibm.com [127.0.0.1]) by ppma06ams.nl.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 1629448Q025335; Fri, 2 Jul 2021 09:05:41 GMT Received: from b06avi18626390.portsmouth.uk.ibm.com (b06avi18626390.portsmouth.uk.ibm.com [9.149.26.192]) by ppma06ams.nl.ibm.com with ESMTP id 39h19bgsdn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 02 Jul 2021 09:05:41 +0000 Received: from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com [9.149.105.62]) by b06avi18626390.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 16293wKq34996604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 2 Jul 2021 09:03:58 GMT Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8DA5CAE058; Fri, 2 Jul 2021 09:05:38 +0000 (GMT) Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 52F8AAE05D; Fri, 2 Jul 2021 09:05:37 +0000 (GMT) Received: from KewenLins-MacBook-Pro.local (unknown [9.200.35.52]) by d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTP; Fri, 2 Jul 2021 09:05:36 +0000 (GMT) Subject: Re: Question on tree LIM To: Richard Biener Cc: GCC Development , "Andre Vieira (lists)" References: <1338ef7b-57f4-a376-5827-c85392ed53a8@linux.ibm.com> From: "Kewen.Lin" Message-ID: <0fd24c58-bcd4-ce7d-d986-bee82d2b7ff5@linux.ibm.com> Date: Fri, 2 Jul 2021 17:05:35 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: mdedv242BHZwXCkA6pyut8IHQ7jLaARt X-Proofpoint-GUID: XqnBjkffpj3JRlst2tWmAQKqJS2snTgd 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-07-02_01:2021-07-02, 2021-07-02 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 bulkscore=0 phishscore=0 adultscore=0 malwarescore=0 clxscore=1011 spamscore=0 mlxscore=0 impostorscore=0 priorityscore=1501 lowpriorityscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2107020051 X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, KAM_SHORT, NICE_REPLY_A, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2021 09:05:50 -0000 Hi Richard, on 2021/7/2 下午4:07, Richard Biener wrote: > On Fri, Jul 2, 2021 at 5:34 AM Kewen.Lin via Gcc wrote: >> >> Hi, >> >> I am investigating one degradation related to SPEC2017 exchange2_r, >> with loop vectorization on at -O2, it degraded by 6%. By some >> isolation, I found it isn't directly caused by vectorization itself, >> but exposed by vectorization, some stuffs for vectorization >> condition checks are hoisted out and they increase the register >> pressure, finally results in more spillings than before. If I simply >> disable tree lim4, I can see the gap becomes smaller (just 40%+ of >> the original), if further disable rtl lim, it just becomes to 30% of >> the original. It seems to indicate there is some room to improve in >> both LIMs. >> >> By quick scanning in tree LIM, I noticed that there seems no any >> considerations on register pressure, it looked intentional? I am >> wondering what's the design philosophy behind it? Is it because that >> it's hard to model register pressure well here? If so, it seems to >> put the burden onto late RA, which needs to have a good >> rematerialization support. > > Yes, it is "intentional" in that doing any kind of prioritization based > on register pressure is hard on the GIMPLE level since most > high-level transforms try to expose followup transforms which you'd > somehow have to anticipate. Note that LIMs "cost model" (if you can > call it such...) is too simplistic to be a good base to decide which > 10 of the 20 candidates you want to move (and I've repeatedly pondered > to remove it completely). > Thanks for the explanation! Do you really want to remove it completely rather than just improve it with a better one? :-\ Here there are some PRs (PR96825, PR98782) related to exchange2_r which seems to suffer from high register pressure and bad spillings. Not sure whether they are also somehow related to the pressure given from LIM, but the trigger is commit 1118a3ff9d3ad6a64bba25dc01e7703325e23d92 which adjusts prediction frequency, maybe it's worth to re-visiting this idea about considering BB frequency in LIM cost model: https://gcc.gnu.org/pipermail/gcc/2014-November/215551.html > As to putting the burden on RA - yes, that's one possibility. The other > possibility is to use the register-pressure aware scheduler, though not > sure if that will ever move things into loop bodies. > Brandly new idea! IIUC it requires a global scheduler, not sure how well GCC global scheduler performs, generally speaking the register-pressure aware scheduler will prefer the insn which has more deads (for that intensive regclass), for this problem the modeling seems a bit different, it has to care about total interference numbers between two "equivalent" blocks (src/dest), not sure if it's easier to do than rematerialization. >> btw, the example loop is at line 1150 from src exchange2.fppized.f90 >> >> 1150 block(rnext:9, 7, i7) = block(rnext:9, 7, i7) + 10 >> >> The extra hoisted statements after the vectorization on this loop >> (cheap cost model btw) are: >> >> _686 = (integer(kind=8)) rnext_679; >> _1111 = (sizetype) _19; >> _1112 = _1111 * 12; >> _1927 = _1112 + 12; >> * _1895 = _1927 - _2650; >> _1113 = (unsigned long) rnext_679; >> * niters.6220_1128 = 10 - _1113; >> * _1021 = 9 - _1113; >> * bnd.6221_940 = niters.6220_1128 >> 2; >> * niters_vector_mult_vf.6222_939 = niters.6220_1128 & 18446744073709551612; >> _144 = niters_vector_mult_vf.6222_939 + _1113; >> tmp.6223_934 = (integer(kind=8)) _144; >> S.823_1004 = _1021 <= 2 ? _686 : tmp.6223_934; >> * ivtmp.6410_289 = (unsigned long) S.823_1004; >> >> PS: * indicates the one has a long live interval. > > Note for the vectorizer generated conditions there's quite some room for > improvements to reduce the amount of semi-redundant computations. I've > pointed out some to Andre, in particular suggesting to maintain a single > "remaining scalar iterations" IV across all the checks to avoid keeping > 'niters' live and doing all the above masking & shifting repeatedly before > the prologue/main/vectorized epilogue/epilogue loops. Not sure how far > he got with that idea. > Great, it definitely helps to mitigate this problem. Thanks for the information. BR, Kewen