From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpbguseast1.qq.com (smtpbguseast1.qq.com [54.204.34.129]) by sourceware.org (Postfix) with ESMTPS id 67AB03858C5F for ; Wed, 8 Nov 2023 08:34:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 67AB03858C5F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivai.ai Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivai.ai ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 67AB03858C5F Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=54.204.34.129 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699432460; cv=none; b=YMdCalmKCDddn1U8mzUVL3wmMO06UDW4xpb9Qwg8BYkkxrLLjFqLB8A1+rodO8XwxUm/vxqIlMY3J/SC303A6wxxD7AMUAbo43j+d4KkkdC+FZ30RUYRCSetfEfI07/2hw+ekH4NgO6Y2GtjLM3faWQpi4dtHKohX5DC2b4reDU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699432460; c=relaxed/simple; bh=5uiDSasrDjTbuSMIa2SxTWEcjybvbYQdAdiAFlmnTyo=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=u9FGJmby9cIUEWWE8HJGIlwH0g9aeVYSPwS0koCc4g0F8OiQGCtOIu7flg9psfqqxzySlC6QePamZqjroADbVa9FYzL+3dvgxfmW2yTAGlZhT85vWkyCsD4uGqCY155UcMe2FupD7c0k1DSPsIHOi/NcS8yNIEpA+V0laFAjt1o= ARC-Authentication-Results: i=1; server2.sourceware.org X-QQ-mid: bizesmtp72t1699432450tpilkd1v Received: from [10.101.11.9] ( [121.35.180.247]) by bizesmtp.qq.com (ESMTP) with id ; Wed, 08 Nov 2023 16:34:09 +0800 (CST) X-QQ-SSF: 01400000000000C0F000000A0000000 X-QQ-FEAT: D6RqbDSxuq6dhyCq9HSaQvVxYo+nRCuXLDvYqtq2oKQ+W0Tgj7MTVnTkVJ5aA Kba6FUypgNreQZogzzGQHslNShO9o5xiusIPwm8Foy4/AGlLhUz6Lnd/Oli2+5ye1cXGCbz kutzHDmLtX+33VryhBRW5YOKj9PHC3l9rK0sRNKArEU6bFrXZAe1dvm2uHooE3xgSDHigDE VfA5ypOMSx2X/+LOCg7hK7PIYDN/uKtDxQ23us9phs2niwzjYo+nHlZaoWvStVaYj37MKCG 40A1iHI/hVUnbqPmlBMTi30Mf+qdKlBeBr6LvCKipVBGBsTyL//Dxmk7Cy39EPh6Pg4s8Jk G7fRVmEUY5iBn3x+itChNJ5Y6e3Gn5Q5LuqLOLLFpjQ5X6hY95z1v+QgY7lZESuFhAfC50a X-QQ-GoodBg: 2 X-BIZMAIL-ID: 13079062215715322670 Message-ID: <5B9F97F20350A9B8+c63a6788-6860-4e71-90e3-d7f2a8cde4d2@rivai.ai> Date: Wed, 8 Nov 2023 16:34:10 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/7] ira: Refactor the handling of register conflicts to make it more general Content-Language: en-US To: Richard Biener Cc: gcc-patches@gcc.gnu.org, vmakarov@redhat.com, richard.sandiford@arm.com, juzhe.zhong@rivai.ai References: <20231108034740.834590-1-lehua.ding@rivai.ai> <20231108034740.834590-2-lehua.ding@rivai.ai> From: Lehua Ding In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:rivai.ai:qybglogicsvrgz:qybglogicsvrgz6a-0 X-Spam-Status: No, score=-8.1 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA,GIT_PATCH_0,KAM_DMARC_STATUS,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Richard, Thanks for taking the time to review the code. On 2023/11/8 15:57, Richard Biener wrote: > On Wed, Nov 8, 2023 at 4:48 AM Lehua Ding wrote: >> >> This patch does not make any functional changes. It mainly refactor two parts: >> >> 1. The ira_allocno's objects field is expanded to an scalable array, and multi-word >> pseduo registers are split and tracked only when necessary. >> 2. Since the objects array has been expanded, there will be more subreg objects >> that pass through later, rather than the previous fixed two. Therefore, it >> is necessary to modify the detection of whether two objects conflict, and >> the check method is to pull back the registers occupied by the object to >> the first register of the allocno for judgment. > > Did you profile this before/after? RA performance is critical ... Based on the data I ran earlier, the performance changes on spec2017 were very slight. I'll run again and give you the data.Based on my expectations, the impact on existing performance should all be minimal. Except for examples like the ones I put up. >> diff --git a/gcc/hard-reg-set.h b/gcc/hard-reg-set.h >> index b0bb9bce074..760eadba186 100644 >> --- a/gcc/hard-reg-set.h >> +++ b/gcc/hard-reg-set.h >> @@ -113,6 +113,39 @@ struct HARD_REG_SET >> return !operator== (other); >> } >> >> + HARD_REG_SET >> + operator>> (unsigned int shift_amount) const > > This is a quite costly operation, why do we need it instead > of keeping an "offset" for set queries? Because there are logic operations after the shift. For a mutil hardreg pseudo register, it will record the physical registers of each part of the conflict, and different parts of the offset are different, and we need to unify these differences to the conflict against the first single reg of the pseduo register. That is to say, first we need to convert it to a conflict against the first_single_reg, and then we need to collect all the conflicting registers (by OR operation). like this: *start_conflict_regs |= OBJECT_TOTAL_CONFLICT_HARD_REGS (obj) >> (OBJECT_START (obj) + j) >> +/* Return the object in allocno A which match START & NREGS. */ >> +ira_object_t >> +find_object (ira_allocno_t a, int start, int nregs) >> +{ >> + for (ira_object_t obj : a->objects) > > linear search? really? I was thinking about the fact that most allocno's have only one objects, and most of the others don't have more than 10, so I chose this easiest way to find them. Thanks for the heads up, it's really not very good here, I'll see if there's a faster way. -- Best, Lehua (RiVAI) lehua.ding@rivai.ai