From patchwork Wed Aug 21 22:54:43 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Law X-Patchwork-Id: 1975140 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=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=Ln2biVu1; 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 4Wq1rR3crPz1ydn for ; Thu, 22 Aug 2024 08:55:19 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 56488385DDF6 for ; Wed, 21 Aug 2024 22:55:17 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) by sourceware.org (Postfix) with ESMTPS id 750FD385EC2A for ; Wed, 21 Aug 2024 22:54:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 750FD385EC2A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 750FD385EC2A Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::335 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1724280891; cv=none; b=E9K2Kt02oQnLsTo61diR3b6hKxD3KLNIRnXDCf062dlY7eNUiNXieq2I7X6mAWmSmxdQDTYqpgcA7fVpaNXaix3Y0dkWMcCAs9cRpOJ+GUuNWN7RtN79GBeL4xD6NN2IlkGBnzyvJpILXGGxP14mhZOJnu9CpkKxgJ/WZLi3k5E= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1724280891; c=relaxed/simple; bh=lB4Mz0y8U5qN9AZh0d+b0a+tsg7fn2uKmVHJ0hWGVSY=; h=DKIM-Signature:Message-ID:Date:MIME-Version:From:To:Subject; b=a+LCcJCcOngPx8bw7FOgLCr37FaLSAv1QCh12B0MiVzCxaalNdeMtFOy9g4Gs+wzSVlsrbZJXgcTDHo/wxCmf5u+LSbgIAyyvwsrxyBNgVkpJTFZ8/NVmgw6Y8L9bVMq3puZ5sihW0VmS5Cr5Oiw5ZZvKGeLJPx8YZoDok4GZRw= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-429da8b5feaso1360035e9.2 for ; Wed, 21 Aug 2024 15:54:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724280888; x=1724885688; darn=gcc.gnu.org; h=subject:to:from:content-language:user-agent:mime-version:date :message-id:from:to:cc:subject:date:message-id:reply-to; bh=/zPrFidwcUrmmA5Y9UfB+I+zYixU7c6zjHRqTMg/+zg=; b=Ln2biVu1I5sA96Goq/5R9hi3DM1wG4wiHTkZZoCYXqG9XgLLwHKuvvVBFZc+MHDmjK pxKsEbAHKpmZ/7fTTixk43E+TprBBl09GTbxfvgQubKcFXRyH83zsE2s7y1VfiN9uXIW s0k+Ao0ZS11mJ3tOheGFy0iSQxUpO39TgWhQfIyXMeiSz0SALUVk/VwiVv9+tVBDD3TN 4N4CeSpFmCSAHt3/4owqE8Ksx4xyu8Tvcg/PqzQZ/WlJu7/9Xjzhr94MRnakl8yiu71i chKK2ET2V3/qOU9hPH3p9NENHIkgUAg2HBUpLBnU4Coi5sr1hTAl9hnXpJnB2QM6Vn6X Rrrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724280888; x=1724885688; h=subject:to:from:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/zPrFidwcUrmmA5Y9UfB+I+zYixU7c6zjHRqTMg/+zg=; b=lFsAs5RhCESHrp1CXfhw7fTrNQgfTkFUDMcAxOMvjcn/qqBHgsgi8u+/bBUPjvYI4/ Ci2wlAceLHDw0G0yHPwnFNpwvNR/xi0Od/vngeP9IPgJptWkJZsdCOppjBvY080b6uEp d72o70eJQI6i91b09Q+VkJhpR4yrbQZ/dbH7OqzyCWX6+yMlLwhwqzU9PH/OE0t1KAou YWlYrbo61i7PmWw//r3dtO12b24ZuRfHsrd6pDgRh2DweQ5f5PnIRWUujcFGae7ozSYf WCJfUl/JeeKOHce2grIXE3TacMXeZP5igNwoUEHLfFXgL7a1YhqOOMjk0QJvzcF8Poa8 nZXw== X-Gm-Message-State: AOJu0YxOq/AJC6eJVV6fyvgdenyaJ0oHwnRCCxi+5fQBu0QtcVb84zgo YIqm91XFAoynLPzIIJ0byZj7AKV9HvF0huzblfG56A00lwaTfNW61w28LA== X-Google-Smtp-Source: AGHT+IH9oNw1/8EVh5sseJao8Bsxw8yhhv+4q3sZTdWxpdaB+CzgHmUDSq3HRPfbFNdjHFVxUbJcLA== X-Received: by 2002:a05:600c:3ba6:b0:426:5520:b835 with SMTP id 5b1f17b1804b1-42ac55b254bmr908895e9.5.1724280887301; Wed, 21 Aug 2024 15:54:47 -0700 (PDT) Received: from [172.31.1.103] ([172.56.168.142]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42ac516251fsm4075795e9.25.2024.08.21.15.54.46 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 21 Aug 2024 15:54:46 -0700 (PDT) Message-ID: Date: Wed, 21 Aug 2024 16:54:43 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Content-Language: en-US From: Jeff Law To: "gcc-patches@gcc.gnu.org" Subject: [committed][PR rtl-optimization/116437] Fix RTL checking issue in ext-dce X-Spam-Status: No, score=-9.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, 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 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 Another RTL checking failure in ext-dce. An easy one to fix this time. When we optimize an extension we have to go back and cleanup with SUBREG_PROMOTED state. So we record the destination register into a bitmap as we make changes, then later do a single pass over the IL fixing any associated subreg expressions. The optimization is changing the SET_SRC and largely ignores the destination. The LHS could be a REG, SUBREG, or ZERO_EXTRACT. If the LHS is a SUBREG or ZERO_EXTRACT we can just strip them. Bootstrapped and ran the testsuite with an RTL checking compiler and verified no ext-dce RTL checking failures tripped. Also bootstrapped and regression tested x86_64 in the usual way. Pushing to the trunk. Jeff commit cdc9cd4afe8949276a0c50215eb7f23e2086044f Author: Jeff Law Date: Wed Aug 21 16:52:23 2024 -0600 [PR rtl-optimization/116437] Fix RTL checking issue in ext-dce Another RTL checking failure in ext-dce. An easy one to fix this time. When we optimize an extension we have to go back and cleanup with SUBREG_PROMOTED state. So we record the destination register into a bitmap as we make changes, then later do a single pass over the IL fixing any associated subreg expressions. The optimization is changing the SET_SRC and largely ignores the destination. The LHS could be a REG, SUBREG, or ZERO_EXTRACT. If the LHS is a SUBREG or ZERO_EXTRACT we can just strip them. Bootstrapped and ran the testsuite with an RTL checking compiler and verified no ext-dce RTL checking failures tripped. Also bootstrapped and regression tested x86_64 in the usual way. Pushing to the trunk. PR rtl-optimization/116437 gcc/ * ext-dce.cc (ext_dce_try_optimize_insn): Handle SUBREG and ZERO_EXTRACT destinations. diff --git a/gcc/ext-dce.cc b/gcc/ext-dce.cc index eee9208f0d6..35c06469b82 100644 --- a/gcc/ext-dce.cc +++ b/gcc/ext-dce.cc @@ -422,8 +422,13 @@ ext_dce_try_optimize_insn (rtx_insn *insn, rtx set) { int ok = validate_change (insn, &SET_SRC (set), new_pattern, false); + rtx x = SET_DEST (set); + while (SUBREG_P (x) || GET_CODE (x) == ZERO_EXTRACT) + x = XEXP (x, 0); + + gcc_assert (REG_P (x)); if (ok) - bitmap_set_bit (changed_pseudos, REGNO (SET_DEST (set))); + bitmap_set_bit (changed_pseudos, REGNO (x)); if (dump_file) {