From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpbgbr2.qq.com (smtpbgbr2.qq.com [54.207.22.56]) by sourceware.org (Postfix) with ESMTPS id 78D923858C53 for ; Fri, 10 Nov 2023 09:26:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 78D923858C53 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 78D923858C53 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=54.207.22.56 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699608377; cv=none; b=IS/Dp6gy3lab2DTz3qR/+/OgrOuS0eGqTPnFvVxrUozCaEQOWnt5TaVVSh3cIuZ8Kwbo8tTRdXOVcMuu3UaWY+Pbryn/frogmCneJHi5xm2qVobCv73DVyiCcnYAmGBPnP5G7biywH44+v6DZ+Rvk+C2XdStzbodfTJNH8uB03k= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699608377; c=relaxed/simple; bh=TCCgBwbJUr0OxlYaRiZmjRVdA5ev+NjkyVrD9yDMjz8=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=KsTfZRYRqH+dpV3yFh6eWeqRXZo2+rodfVLblRMoZeQajbVkdUQfQT7kiskan472xWVax/1kVUXAvMJk8iYW5BulBIUJEXYcabaVId4J+3a+zYgAZo1pjTsRMy+qEwBkcQ1RcH1Zh0v1nR+l4HYnA3M6D4Lz7QwApV+yX0kTS8Q= ARC-Authentication-Results: i=1; server2.sourceware.org X-QQ-mid: bizesmtp84t1699608367tyh3l6x9 Received: from [10.101.11.9] ( [121.35.180.247]) by bizesmtp.qq.com (ESMTP) with id ; Fri, 10 Nov 2023 17:26:05 +0800 (CST) X-QQ-SSF: 01400000000000C0F000000A0000000 X-QQ-FEAT: 93xFIsmJpAWPT2Isb4obRaEwZe35Zw5l2FZm5J5sl1R1p70ORymYH1WoCiETN EXZ0G8xusEgciCPCYjEMkRWYb7l35CrJPmV4v8IcSkQ2w/x2UCmMZDHF7gQgiaac0T8fyv1 dXtAFgcclBK5fxTqsOTY7KyNNSGZmM2D2fXEkRYvfWwXOilB8P5TgR7y1vUDvOk//IqTWJ9 HIqJ/Ye4dbMeHJTEb3F49InmJvMTfc518zirjyWh2PbDOSn/odNKItKkIDGA3Rs7KrhorjU cZN5sn3j9lXRKTkBTwQrY1aQuvJ53wapFSCrLrOp6g0dbEubIY7sm3Gh61mhPZPvoklpHgO PfsUxHWKJ8GAxyBr4WRpfIj94oazhnEy/l+vONcHkLJz4aPmtLlsRBu5/4fOnQMkVLcSsGp X-QQ-GoodBg: 2 X-BIZMAIL-ID: 7526404962170913187 Message-ID: <1271847054F02C54+aff62c2d-3647-4801-a2c1-153a68cca1e2@rivai.ai> Date: Fri, 10 Nov 2023 17:26:06 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/7] ira/lra: Support subreg coalesce Content-Language: en-US To: gcc-patches@gcc.gnu.org, vmakarov@redhat.com, juzhe.zhong@rivai.ai, richard.sandiford@arm.com References: <20231108034740.834590-1-lehua.ding@rivai.ai> From: Lehua Ding In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:rivai.ai:qybglogicsvrgz:qybglogicsvrgz6a-0 X-Spam-Status: No, score=-0.1 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA,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=no 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, On 2023/11/8 17:40, Richard Sandiford wrote: > Tracking subreg liveness will sometimes expose dead code that > wasn't obvious without it. PR89606 has an example of this. > There the dead code was introduced by init-regs, and there's a > debate about (a) whether init-regs should still be run and (b) if it > should still be run, whether it should use subreg liveness tracking too. > > But I think such dead code is possible even without init-regs. > So for the purpose of this series, I think the init-regs behaviour > in that PR creates a helpful example. Yes, I think the init-regs should be enhanced to reduce unnecessary initialization. My previous internal patchs did this in a separate patch. Maybe I should split the live_subreg problem out of the second patch and not couple it with these patches. That way it can be reviewed separately. > I agree with Richi of course that compile-time is a concern. > The patch seems to add quite a bit of new data to ira_allocno, > but perhaps that's OK. ira_object + ira_allocno is already quite big. > > However: > > @@ -387,8 +398,8 @@ struct ira_allocno > /* An array of structures describing conflict information and live > ranges for each object associated with the allocno. There may be > more than one such object in cases where the allocno represents a > - multi-word register. */ > - ira_object_t objects[2]; > + multi-hardreg pesudo. */ > + std::vector objects; > /* Registers clobbered by intersected calls. */ > HARD_REG_SET crossed_calls_clobbered_regs; > /* Array of usage costs (accumulated and the one updated during > > adds an extra level of indirection (and separate extra storage) for > every allocno, not just multi-hardreg ones. It'd be worth optimising > the data structures' representation of single-hardreg pseudos even if > that slows down the multi-hardreg code, since single-hardreg pseudos are > so much more common. And the different single-hardreg and multi-hardreg > representations could be hidden behind accessors, to make life easier > for consumers. (Of course, performance of the accessors is also then > an issue. :)) Okay, I'll try. Thank you so much. -- Best, Lehua (RiVAI) lehua.ding@rivai.ai