From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) by sourceware.org (Postfix) with ESMTPS id 0DE383858C78 for ; Tue, 28 Nov 2023 13:37:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0DE383858C78 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=embecosm.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0DE383858C78 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::62d ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701178624; cv=none; b=AV/oFWBdHDJc7xQzM97UdWS2qcmfYSCl9zoCEEozbr40MjvtmgpCPH8/f4dlpiQr9N5Oe5CpPhaMfHAQgZnii4x3mh/a+p6o/90WAVx0yoq5fkmbEWcYDiNajYgsej9SkdGfS6VdZXvaCNTfh+8kKLykT9XT19hOflKsgtuZStc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701178624; c=relaxed/simple; bh=nLu5vv3xWoSMRwROTJvr4oBDxvrW16FkRHcdCV2Znvo=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=b0RUjNQS923rk3E8ShNB6GiFKVk8ekd09cZDklM3qYAhw7yfyBEV0nzkwAiGaoq0/YuY5DgItyCHdQP2kgDXIsh9snZ7U6FT96KqAe5c3GoOHobi9Zjwk/kOyGiNI1TobwVe+S0I3lOd+OBgYDOIezdBHWbpXZjx0HVdOtkX5dI= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pl1-x62d.google.com with SMTP id d9443c01a7336-1cff3a03dfaso7480745ad.3 for ; Tue, 28 Nov 2023 05:37:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; t=1701178622; x=1701783422; darn=gcc.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=wTYXhKNUkx1hdjBhY9mxrhuxBwjO1UGHO8hN8R5tC9M=; b=UNcYbQ5XpvnXw4LabRS0BLSloPc8yyvGI5RKBUQZYbg0qtJqkBam2g608UsME5M7cZ tLuoaNPodJfMaqV9U9bxCef0lSbv91qn2r2REfqpTzNbZ1yoHUia79+vU99uQ7Y00+p/ fTBgN5RCudatx2HuZkfsOWPp2pOM8XKXQ16aCgzT/cy1HHWOkehr6h/Bz3cUXJK4Dfhd AHlSB90jLQR/l4/wXIoKe6mQDEeOs1aWchoTIJ4LRKPpk+IQ1Po4OTdcczJkjzYxfiTB VqDdFIr0igTPZ7CT0C6/Gcix7V6ElzzJn4Bdkn292oL2m/c50HdrS/xVGOAvMO3OuZIa ktCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701178622; x=1701783422; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=wTYXhKNUkx1hdjBhY9mxrhuxBwjO1UGHO8hN8R5tC9M=; b=HaZRsiM9W5qnAPoaJvbzSPj6WRMUQ3/eGHCuydxYjd5tbg5u3GzFhViXnIKQMLWUlU WQUsxzpMfqPWFHeUd7Dtlb69E109zBn/MbiOD8ZF9CpeA/RVX/17GYyUdj5omPqYpkxK ORWl4ocyiOlmo1x0mJr1xOQxcWYkfAChMOcSNEaVQ5MlIqncgIIt4OzT1+YweVfWkdVY SM3D2BGMc7QyUpmSDQrbily/yXpT3gxNidRt40MjhsFdVVZ4O1mLX2+Kb3HrKzcU/EEw IpewfY7mxrFJlVC+c9PecMczM4XxIfB2XDOhcimwYiHL325JGZdmki31YP+qLOdfenMq 0fAA== X-Gm-Message-State: AOJu0YynLRTgfhvBu3scMb1Jave20NLjwnoYxP+2JVOuGnJj6VMm3Q+H HsyM2wYxtBE+RKi5ZTBKerPfTSebZgJpKKMtVX2HNQ== X-Google-Smtp-Source: AGHT+IE+vwuKpOXB0G0QPhU35mSLn2SPtcMXUU/NCfe5ex5BWS+UBT5dt80TGo1zB3xKnkHk5/mYhyAxL6/oof38NK8= X-Received: by 2002:a17:90b:1bc8:b0:285:ba29:4ba with SMTP id oa8-20020a17090b1bc800b00285ba2904bamr7816026pjb.7.1701178621737; Tue, 28 Nov 2023 05:37:01 -0800 (PST) MIME-Version: 1.0 References: <51510aa5-eb02-47a4-86c3-ecaa13ce26af@ventanamicro.com> In-Reply-To: <51510aa5-eb02-47a4-86c3-ecaa13ce26af@ventanamicro.com> From: Joern Rennecke Date: Tue, 28 Nov 2023 13:36:50 +0000 Message-ID: Subject: Re: [RFA] New pass for sign/zero extension elimination To: Jeff Law Cc: GCC Patches , richard.sandiford@arm.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, 27 Nov 2023 at 20:18, Jeff Law wrote: > > > > On 11/27/23 13:03, Richard Sandiford wrote: > > Joern Rennecke writes: > >> On 11/20/23 11:26, Richard Sandiford wrote: > >>>> + /* ?!? What is the point of this adjustment to DST_MASK? */ > >>>> + if (code == PLUS || code == MINUS > >>>> + || code == MULT || code == ASHIFT) > >>>> + dst_mask > >>>> + = dst_mask ? ((2ULL << floor_log2 (dst_mask)) - 1) : 0; > >>> > >>> Yeah, sympathise with the ?!? here :) > >> Jeff Law: > >>> Inherited. Like the other bit of magic I think I'll do a test with them > >>> pulled out to see if I can make something undesirable trigger. > >> > >> This represents the carry effect. Even if the destination only cares about > >> some high order bits, you have to consider all lower order bits of the inputs. > >> > >> For ASHIFT, you could refine this in the case of a constant shift count. > > > > Ah, right. Think it would be worth a comment. > Definitely. Wouldn't SIGN_EXTEND have a similar problem? While we > don't care about all the low bits, we do care about that MSB. Yes, if bits outside of the MODE_MASK of the input (i.e. higher bits) are life in the output, than we want the high bit of the SIGN_EXTEND input live. OTOH, if the output is not wider, then the high bit of the input is only life if the same bit of the output is. That latter point is important because chains of same-width sign extends are a prime target for this optimization. SMUL_HIGHPART / UMUL_HIGHPART also have carry-propagation. With the saturating operations, we also have propagations from high bit into lower bits in the saturating case. I don't think we can do anything useful for the saturating addition / multiplication operators safely. For the saturating truncation operations, we have the high-to-low propagation, but no low-to-high propagation, so that would be something separate to model.