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 896F73858D1E for ; Sat, 11 Nov 2023 15:33:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 896F73858D1E 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 896F73858D1E 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=1699716799; cv=none; b=wdYigZYhvqMjg5CkmPyiDwmN63UWa2tQk84+CA3RYcQC6WpjWHpm+ig66FQOwr8uCAJKtb//X+VydKyh81TYUXT4pdFXi24HXLJGzcLt+VmRhPSis8RSR689OPuxkwOhWzBPWVDeCo7+cvDNZu/uvssLpc9Je5cPmnLlQRYE6nU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699716799; c=relaxed/simple; bh=3F8au+Ryhj58o9t+YNXoi4Ca0OGHzccLvzn/a9qAdSw=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=hI0G2wV6DqUyN1Oqcf+/5J8lyR5aliFqq2Jhp6D1Jm5pdnMutXXCA0bZ8RgiUKrg2a9A1u6Orux+hxp3QrolYo9GR5AIJ6rMEYU3f4YgpvyvP/XDcY3REILz6S8kj4Urucga/WQz+bO28wV8KyXXXs7g66uCyaZ8AUr9lo2lU1M= 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 012FC12FC; Sat, 11 Nov 2023 07:34:03 -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 59E923F64C; Sat, 11 Nov 2023 07:33:17 -0800 (PST) From: Richard Sandiford To: Jeff Law Mail-Followup-To: Jeff Law ,Lehua Ding , gcc-patches@gcc.gnu.org, vmakarov@redhat.com, juzhe.zhong@rivai.ai, richard.sandiford@arm.com Cc: Lehua Ding , 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> <3d6ec0ee-6542-4b6a-a2cd-7fd54c136af9@gmail.com> Date: Sat, 11 Nov 2023 15:33:16 +0000 In-Reply-To: <3d6ec0ee-6542-4b6a-a2cd-7fd54c136af9@gmail.com> (Jeff Law's message of "Wed, 8 Nov 2023 12:13:45 -0700") 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: Jeff Law writes: > On 11/8/23 02:40, Richard Sandiford wrote: >> 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: > Absolutely agreed on the above. > > The other thing to ponder. Jivan and I have been banging on Joern's > sub-object tracking bits for a totally different problem in the RISC-V > space. But there may be some overlap. > > Essentially Joern's code tracks liveness for a few chunks in registers. > bits 0..7, bits 8..15, bits 16..31 and bits 32..63. This includes > propagating liveness from the destination through to the sources. SO > for example if we have > > (set (reg:SI dest) (plus:SI (srcreg1:SI) (srcreg2:SI))) > > If we had previously determined that only bits 0..15 were live in DEST, > then we'll propagate that into the source registers. > > The goal is to ultimately transform something like > > (set (dest:mode) (any_extend:mode (reg:narrower_mode))) > > into > > (set (dest:mode) (subreg:mode (reg:narrower_mode))) > > Where the latter typically will get simplified and propagated away. > > > Joern's code is a bit of a mess, but Jivan and I are slowly untangling > it from a correctness standpoint. It'll also need the usual cleanups. Ah, nice! How configurable are the bit ranges? We might be able to use something similar to track lanes in a vector operation, to detect the dead code in: ins v0.b[4], w0 ... ins v0.b[4], w1 It sounds like the bit ranges you have now would do that for some common/useful cases, even if it doesn't handle the general case. Maybe dead lanes are better tracked at the gimple level though, not sure. (But AArch64 might need to lower lane operations more than it does now if we want gimple to handle it.) Richard