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 404713858C2D for ; Mon, 27 Nov 2023 20:15:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 404713858C2D 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 404713858C2D 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=1701116122; cv=none; b=IIeZTTny+EHtK3fSwXIEnIF0VEWCdD5Yfdnnmu3Q2JfsGQimw7n/lLWc16jCN1VRsrHZUKuYoWFid66x60Czzj9Vv7zmNNQK0DbXfAK5ukcVlhjnEVyOrvdDla/oWcuwioAMOIGhD7zKu86cWqD9krRdW7xxquAGfguJBMmg8II= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701116122; c=relaxed/simple; bh=vAnsHBfDvq9Hr1M8HFA+D8itjzxGG9MgwykfkjEWHWI=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=U4C14QMJAIzLVQPUPWrGC+OdvVrg3C4av0vJj+44j1EhJI6J1gpT8iXb69oNT7xtYM25OJ6LLnUx7Twj8m+CC6OZ53m1FpX0BaJvOWmH0vKpujmjizwzb+Wur+HOu2ZTvrWpZMN1eFIqNsOdW6FcGghnj7mJsgEGN79sHRgCMH8= 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 99DC71FB; Mon, 27 Nov 2023 12:16: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 48EFD3F5A1; Mon, 27 Nov 2023 12:15:20 -0800 (PST) From: Richard Sandiford To: Jeff Law Mail-Followup-To: Jeff Law ,"gcc-patches\@gcc.gnu.org" , Jivan Hakobyan , richard.sandiford@arm.com Cc: "gcc-patches\@gcc.gnu.org" , Jivan Hakobyan Subject: Re: [RFA] New pass for sign/zero extension elimination References: <6d5f8ba7-0c60-4789-87ae-68617ce6ac2c@ventanamicro.com> <929d7ab8-7ca2-4cd7-a68b-1a24862c7077@ventanamicro.com> Date: Mon, 27 Nov 2023 20:15:19 +0000 In-Reply-To: <929d7ab8-7ca2-4cd7-a68b-1a24862c7077@ventanamicro.com> (Jeff Law's message of "Wed, 22 Nov 2023 10:59:04 -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=-16.5 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: [Sorry for the slow response] Jeff Law writes: > On 11/20/23 11:26, Richard Sandiford wrote: >> >> scalar_int_mode outer_mode; >> if (!is_a (GET_MODE (x), &outer_mode) >> || GET_MODE_BITSIZE (outer_mode) > 64) >> continue; > Wouldn't we also want to verify that the size is constant, or is it the > case that all the variable cases are vector (and would we want to > actually depend on that)? Yeah, all the variable cases are vectors. We don't support variable-length scalars at the moment. (And I hope that never changes. :)) >>> + /* We will handle the other operand of a binary operator >>> + at the bottom of the loop by resetting Y. */ >>> + if (BINARY_P (src)) >>> + y = XEXP (src, 0); >> >> What about UNARY_P, given that NOT is included in the codes above? > We'll break that inner for(;;) then iterate into the subobject, marking > the relevant bits live. FWIW, the control flow of this code continues > to be my biggest concern from a maintenance standpoint. Figuring it out > was a major pain and I've tried to document what is and what is not > safe. But it's still painful to walk through. > > I pondered if note_uses/note_stores would be better, but concluded we'd > just end up with a ton of state objects to carry around and reasoning > about that would be just as hard. Feels like it would be good to handle the top-level structure explicitly, (PARALLELs, SETs, SET_SRCs, etc.), then fall back to iteration at the point that we can no longer do better then "all registers in this expression are fully live". If we do that, rtx_properties might be an alternative to explicit iteration. The advantage of that is that it can handle destination and sources as the top-level expression, and records whether each register is itself a destination or source. Thanks, Richard