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 2F1EF3858C62 for ; Wed, 3 Jan 2024 16:54:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2F1EF3858C62 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 2F1EF3858C62 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=1704300880; cv=none; b=Ym2rz6n6mJfab732VB66n0jwtEdAhfqmjfmtVMRa8x1mH5XfhLWmZQnVW18QLi3pNEi+e7o7JQU6GHknbf4qqXkEdgFy1+ThKmPMSFW0MPNpZ5KMCKy5EhoZ/OmJ+tMVr3c36hNwZr8T7SSePV4PvhcIVjEpQn3iKAof17DewEI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1704300880; c=relaxed/simple; bh=f4N5Jo83RgGnxdcBNy6GH+ZRXoyK0RI/oBtqwCBnlsg=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=cpYW39YwU3XxJl5us39wzfH6IVMoIfo30eCEaPQIlOVYz4viHcpM+OZpizB+LNIHT2Ym1qM4FmtkftAxLopfNM+2YRfAnlWkzdhJphlcpOzzmC8Ey5WySUl/NGfI/TP0a75Ht0gyCAUDrdUWDYGDow+B34sxH/K9WiKTtDvxNWE= 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 A4BEAC15; Wed, 3 Jan 2024 08:55:22 -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 56D263F7A6; Wed, 3 Jan 2024 08:54:36 -0800 (PST) From: Richard Sandiford To: Jeff Law Mail-Followup-To: Jeff Law ,"gcc-patches\@gcc.gnu.org" , richard.sandiford@arm.com Cc: "gcc-patches\@gcc.gnu.org" Subject: Re: [RFA] [V3] new pass for sign/zero extension elimination References: <49a49758-e209-4022-991a-b5d3866cf248@ventanamicro.com> Date: Wed, 03 Jan 2024 16:54:35 +0000 In-Reply-To: (Richard Sandiford's message of "Wed, 03 Jan 2024 12:07:54 +0000") 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=-15.6 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: Richard Sandiford writes: > Jeff Law writes: >> [...] >> + if (GET_CODE (x) == ZERO_EXTRACT) >> + { >> + /* If either the size or the start position is unknown, >> + then assume we know nothing about what is overwritten. >> + This is overly conservative, but safe. */ >> + if (!CONST_INT_P (XEXP (x, 1)) || !CONST_INT_P (XEXP (x, 2))) >> + continue; >> + mask = (1ULL << INTVAL (XEXP (x, 1))) - 1; >> + bit = INTVAL (XEXP (x, 2)); >> + if (BITS_BIG_ENDIAN) >> + bit = (GET_MODE_BITSIZE (GET_MODE (x)) >> + - INTVAL (XEXP (x, 1)) - bit).to_constant (); >> + x = XEXP (x, 0); > > Should mask be shifted by bit here, like it is for the subregs? E.g.: > > (set (zero_extract:SI R (const_int 2) (const_int 7))) > > would currently give a mask of 0x3 and a bit of 7, whereas I think it > should be a mask of 0x180. Without that we would only treat the low 8 > bits of R as live, rather than the low 16 bits. Or I suppose more to the point... >> + >> + /* We can certainly get (zero_extract (subreg ...)). The >> + mode of the zero_extract and location should be sufficient >> + and we can just strip the SUBREG. */ >> + if (SUBREG_P (x)) >> + x = SUBREG_REG (x); >> + } >> + >> + /* BIT >= 64 indicates something went horribly wrong. */ >> + gcc_assert (bit <= 63); >> + >> + /* Now handle the actual object that was changed. */ >> + if (REG_P (x)) >> + { >> + /* Transfer the appropriate bits from LIVENOW into >> + LIVE_TMP. */ >> + HOST_WIDE_INT rn = REGNO (x); >> + for (HOST_WIDE_INT i = 4 * rn; i < 4 * rn + 4; i++) >> + if (bitmap_bit_p (livenow, i)) >> + bitmap_set_bit (live_tmp, i); >> + >> + /* Now clear the bits known written by this instruction. >> + Note that BIT need not be a power of two, consider a >> + ZERO_EXTRACT destination. */ >> + int start = (bit < 8 ? 0 : bit < 16 ? 1 : bit < 32 ? 2 : 3); >> + int end = ((mask & ~0xffffffffULL) ? 4 >> + : (mask & 0xffff0000ULL) ? 3 >> + : (mask & 0xff00) ? 2 : 1); >> + bitmap_clear_range (livenow, 4 * rn + start, end - start); ...these assumptions don't seem safe for a ZERO_EXTRACT. Unlike for the other destinations, IIUC we can only clear liveness bits if the ZERO_EXTRACT writes to *all* of the bits in the range, rather than some of them. The bits that aren't explicitly written to are preserved. So... > [...] > But for now it might be simpler to remove ZERO_EXTRACT from the "else if" > and leave a FIXME, since continuing will be conservatively correct. ...I think this applies more generally. It might be safer to handle ZERO_EXTRACT conservatively for GCC 14 and only try to optimise it in GCC 15. Thanks, Richard