From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 7766C385609B for ; Fri, 10 Nov 2023 10:16:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7766C385609B Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7766C385609B Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=217.140.110.172 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699611401; cv=none; b=LTJx7AKXJEQ30lwpo/86OHwEXAz5wq1dqJKlPPLasn+UEq0ShKRzNyWE0BHSr1n0/N0OUSiBOQrCQ2hGAzGgUFLKRWx9riRhtCWuZr5RKKYbGDsJqzykTRq8PmCOqnuHqK3l0g2DWate2gXq0rsGjOeT0R+pV2OeZXQzXuyK2WI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699611401; c=relaxed/simple; bh=4WUNFkB1KJpULaxL4adE94XW0Uc8b8EJE60xTpzN4ac=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=DzZR8bPs1ekrCdXsqDRS2bVVHo8kbD6bTuSxU6onD/5I+pMTfC4mQ3wTqX/QepJFH9Zq5AzYyNSF99cXC9doxvpPgXHcLU/UVj9Z+EnizSPncPzQ1rcFBR53N0JluZx8Xl8aMUpgCIMuSqlwFQjoS7WiFXoI/pUb3lyCAjpcb4I= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 11B71106F; Fri, 10 Nov 2023 02:17:23 -0800 (PST) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C070E3F6C4; Fri, 10 Nov 2023 02:16:37 -0800 (PST) From: Richard Sandiford To: Lehua Ding Mail-Followup-To: Lehua Ding ,gcc-patches@gcc.gnu.org, vmakarov@redhat.com, juzhe.zhong@rivai.ai, richard.sandiford@arm.com Cc: gcc-patches@gcc.gnu.org, vmakarov@redhat.com, juzhe.zhong@rivai.ai Subject: Re: [PATCH 0/7] ira/lra: Support subreg coalesce References: <20231108034740.834590-1-lehua.ding@rivai.ai> <1271847054F02C54+aff62c2d-3647-4801-a2c1-153a68cca1e2@rivai.ai> Date: Fri, 10 Nov 2023 10:16:36 +0000 In-Reply-To: <1271847054F02C54+aff62c2d-3647-4801-a2c1-153a68cca1e2@rivai.ai> (Lehua Ding's message of "Fri, 10 Nov 2023 17:26:06 +0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-17.1 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,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: Lehua Ding writes: > 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. But my point was that this kind of dead code is possible even without init-regs. So I think we should have something that removes the dead code. And we can try it on that PR (without changing init-regs). Thanks, Richard > >> 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.