From patchwork Mon Jul 22 16:15:57 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Law X-Patchwork-Id: 1963328 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=ventanamicro.com header.i=@ventanamicro.com header.a=rsa-sha256 header.s=google header.b=aNCyEj4F; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=2620:52:3:1:0:246e:9693:128c; helo=server2.sourceware.org; envelope-from=gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=patchwork.ozlabs.org) Received: from server2.sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4WSQQ011qbz1yZ7 for ; Tue, 23 Jul 2024 02:16:23 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 040C63858C33 for ; Mon, 22 Jul 2024 16:16:22 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) by sourceware.org (Postfix) with ESMTPS id 9FF353858C52 for ; Mon, 22 Jul 2024 16:16:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9FF353858C52 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=ventanamicro.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ventanamicro.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 9FF353858C52 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::22d ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1721664962; cv=none; b=vp91Go5RayTEpACMhTcjFogQogwcZApDg52Kcz9nqGGYOfEgZF/XswLV+cLQlZxvvzh6PwZEOH7EtT+Ff7XGhd80dpcTMfQ/tpAzWpgq2IaIWyS1utpCBkm5RZtGVo4vAYrJgOiIF4aFk31BMIoRGVSArX7FfM1odX0QO8ksbB4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1721664962; c=relaxed/simple; bh=B2ATouaOLWQdSbVvbEyWujB2dC3r0EBBtD+fFbbFjyQ=; h=DKIM-Signature:Message-ID:Date:MIME-Version:From:Subject:To; b=Bb90GniPohpH8wUdfsLhAdRNUQZtMLy6VtGVi8x0TtQBsMjUSi2Ost66gdniWER/pgd8bNFNEFCh3c/hxmZThlklCmN9FKBmJiuxmb0/pF36qxsN26ks8L6MTdsawz9fs8GfaXiNOePwnxRbRdJ1iG/fB1OS5GPLwjMnscmMQOo= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-oi1-x22d.google.com with SMTP id 5614622812f47-3d9400a1ad9so2550829b6e.1 for ; Mon, 22 Jul 2024 09:16:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1721664959; x=1722269759; darn=gcc.gnu.org; h=to:subject:from:content-language:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=g4lyIGwA/ebB+EmI2F9a7uZlyudBmfY2s6UNEhJK4fY=; b=aNCyEj4FiPpmLDBE5yeqISVb/Bv7axktbBvILeTEAUtgnuc+Cxm0HFZ//enpJCT8LP rmh55x7jwj7Rlf3Dld9ItiRBQ12LiKN9vQnNQpr5TRrxP26qlhICLvry0UGqy1Y/t3D2 W8MwheWaD3I5l1Kyvv5tHq3kNECEH3o3sEU53TDlA40UrMP1+GKT1SA2vsWcb+ZJ1DjS fDQA5CCiwbEhY01pt1/i/VHRs175HKGJkpsXaPfQDcYRj/2nrt3MFiHEYjy41XnGRrRA TuWfbqSL0rZiEsdEvfunvilnxpjmiHubpBKDlukv49s9gzAgj3+xLEZpmsMM7g1d+lYx NVbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721664959; x=1722269759; h=to:subject:from:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=g4lyIGwA/ebB+EmI2F9a7uZlyudBmfY2s6UNEhJK4fY=; b=Mk22T7wOLZkMho9j01l5fRQ/Ttm87gUNxXEs2ZmIIy/l0XL3t8bHgxSzSzzXmEHHCH N1ojyVp16nQEjCvzgMj83sHUnZ8Z7H+RNMsA7VHwRbH75MTS0hM9pDvoIbrhp4fl0XsS 24W/0V3oK+sxS60GoCXezki7xLgz+6GMQWUd+KPvKud0ECmC5sX0TjCF4B/kYbZtQ7ak wbK8skQmY5MS/E5hA/IKpNW8in826ZKJrp8XYeiZV4zjuhGiNyZhjYfbW1i2qnisDf3x csRhVo+vrt+xle2tsYp2CuPJGK4xSLiPrbZm46YxWisisslAslA9v6uVrCjVenycZg8S lPwg== X-Gm-Message-State: AOJu0YwTWhGwMX0kUHwzjpYNS4fWKJOKj4vw8YBE50erdemIn7OeyPtJ ckLsAapO2/ML3HgFpwynxt8IQOwTh0AsItxTAaAVELbChg8QWxSMdl1CPdUy7to9qYUW8eZY8E8 NXxc= X-Google-Smtp-Source: AGHT+IEaQYC6I0oMh4gSIWMXGIuXyUZJkZvIwzbrETDA80ZUczBM5pCHIcQR5zaU1aUxHG7Vo6nldw== X-Received: by 2002:a05:6830:61cd:b0:703:5ab1:64d4 with SMTP id 46e09a7af769-708fdbb4223mr12753478a34.29.1721664958896; Mon, 22 Jul 2024 09:15:58 -0700 (PDT) Received: from [172.31.0.109] ([136.36.72.243]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-708f60d3560sm1580104a34.31.2024.07.22.09.15.58 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Jul 2024 09:15:58 -0700 (PDT) Message-ID: <5eedb951-d5e5-4d16-99f0-b676e360e263@ventanamicro.com> Date: Mon, 22 Jul 2024 10:15:57 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Content-Language: en-US From: Jeff Law Subject: [committed][4/n][PR rtl-optimization/115877] Correct SUBREG handling in a destination To: "gcc-patches@gcc.gnu.org" X-Spam-Status: No, score=-11.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces~incoming=patchwork.ozlabs.org@gcc.gnu.org If we encounter something during SET handling that we can not handle, the safe thing to do is to ignore the destination and continue the loop. We've actually been trying to do slightly better with SUBREG destinations by iterating into SUBREG_REG. It turns out that wasn't working as expected. The problem is once we "continue" we lose the state that we were inside the SET and thus we ended up ignoring the destination completely rather than tracking the SUBREG_REG object. This could be fixed by restarting SET processing, but I just don't see this as all that important to handle. So rather than leave the code as-is, not working per design, I'm twiddling it to use the common 'skip subrtxs and continue' idiom used elsewhere. This is a prerequisite for another patch in this series. Specifically I have a patch that explicitly tracks if we skipped a destination rather than trying to imply it from the state of LIVE_TMP. So this is probably NFC right now, but that's a short-lived NFC. Bootstrapped and regression tested on x86 and also run as part of a larger kit on the crosses in my tester. Pushing to the trunk, Jeff commit ab7c0aed52054976d0b5e12c52e82239d4277b98 Author: Jeff Law Date: Mon Jul 22 10:11:57 2024 -0600 [4/n][PR rtl-optimization/115877] Correct SUBREG handling in a destination If we encounter something during SET handling that we can not handle, the safe thing to do is to ignore the destination and continue the loop. We've actually been trying to do slightly better with SUBREG destinations by iterating into SUBREG_REG. It turns out that wasn't working as expected. The problem is once we "continue" we lose the state that we were inside the SET and thus we ended up ignoring the destination completely rather than tracking the SUBREG_REG object. This could be fixed by restarting SET processing, but I just don't see this as all that important to handle. So rather than leave the code as-is, not working per design, I'm twiddling it to use the common 'skip subrtxs and continue' idiom used elsewhere. This is a prerequisite for another patch in this series. Specifically I have a patch that explicitly tracks if we skipped a destination rather than trying to imply it from the state of LIVE_TMP. So this is probably NFC right now, but that's a short-lived NFC. Bootstrapped and regression tested on x86 and also run as part of a larger kit on the crosses in my tester. PR rtl-optimization/115877 gcc/ * ext-dce.cc (ext_dce_process_sets): More correctly handle SUBREG destinations. diff --git a/gcc/ext-dce.cc b/gcc/ext-dce.cc index 44f64e2d18c..21feabd9ce3 100644 --- a/gcc/ext-dce.cc +++ b/gcc/ext-dce.cc @@ -270,11 +270,18 @@ ext_dce_process_sets (rtx_insn *insn, rtx obj, bitmap live_tmp) = GET_MODE_MASK (GET_MODE_INNER (GET_MODE (x))); if (SUBREG_P (x)) { - /* If we have a SUBREG that is too wide, just continue the loop - and let the iterator go down into SUBREG_REG. */ + /* If we have a SUBREG destination that is too wide, just + skip the destination rather than continuing this iterator. + While continuing would be better, we'd need to strip the + subreg and restart within the SET processing rather than + the top of the loop which just complicates the flow even + more. */ if (!is_a (GET_MODE (SUBREG_REG (x)), &outer_mode) || GET_MODE_BITSIZE (outer_mode) > 64) - continue; + { + iter.skip_subrtxes (); + continue; + } /* We can safely strip a paradoxical subreg. The inner mode will be narrower than the outer mode. We'll clear fewer bits in