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 BD4573858D1E for ; Wed, 8 Nov 2023 09:40:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org BD4573858D1E 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 BD4573858D1E 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=1699436427; cv=none; b=OSdQU2lhJsOoo6Rpcr3CxNhaz4e4jyKebMHmpmdtt8gPoHJVzixs0CkZXPUeHc0doNk7Gs+qZwbTeD5YRcdMbwOQdr0efeQgg90dkSay0u56TSs0RaUeNWXXn2hphgeApu/oJ2PydYAU2zZIfeeH2QoOYx4C9skjOzPiA2C3ZBY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699436427; c=relaxed/simple; bh=6vOFwkvkS2TMSBaY89HDnTRd228wEx00hEuySwrd5nA=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=i9WORZg0Z51HmG93i0WOULUaa1ir2gMSHaukX5Rsi8gCxbEOnKrBM4agDZNp3jsfDdn5OVuz/nVeJ/p3qZZS1QYw8yl4YcXAO+rd3kHVWx7296FuShrvCGqIOkkLmdJQHfePOtcbkcnQf9wORfcXYu3w36heZni7BvuDmv7/Mtc= 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 965051476; Wed, 8 Nov 2023 01:41:08 -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 821893F64C; Wed, 8 Nov 2023 01:40:23 -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> Date: Wed, 08 Nov 2023 09:40:22 +0000 In-Reply-To: <20231108034740.834590-1-lehua.ding@rivai.ai> (Lehua Ding's message of "Wed, 8 Nov 2023 11:47:33 +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.2 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, > > These patchs try to support subreg coalesce feature in > register allocation passes (ira and lra). Thanks a lot for the series. This is definitely something we've needed for a while. I probably won't be able to look at it in detail for a couple of weeks (and the real review should come from Vlad anyway), but one initial comment: 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. 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. :)) Richard