From patchwork Tue Jul 30 20:22:55 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Law X-Patchwork-Id: 1966753 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=l32EVD/b; 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 4WYRXJ6zgwz1ybX for ; Wed, 31 Jul 2024 06:24:16 +1000 (AEST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 086AD385C6C1 for ; Tue, 30 Jul 2024 20:24:15 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id 348A83858C3A for ; Tue, 30 Jul 2024 20:23:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 348A83858C3A 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 348A83858C3A Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::631 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1722371029; cv=none; b=RzsIGf1srVWzZyornAHnOrO+reyjbBhg5nzDQH3qmgCeOoUZVUL2yYi/rwi7+4BzR4jcD/fjvflQO5RMv0SUT8BFxMrWn+ZRBbm/7J1eLdkBM2gOlDbRqcT8mZqJBu/FQXFhfMj9E6/kRjAtZZl2nRlo46M+8d0K/1jOzu3DgII= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1722371029; c=relaxed/simple; bh=7DFLQ7dBQik4hjDDIwRkCQT0dvWgen0kciryxYsUF5Q=; h=DKIM-Signature:Message-ID:Date:MIME-Version:From:To:Subject; b=e+luVG5+lGkAO98Gc1cKNfxJ9lLgjEf+shWpwWTyf+p/PZBVzTV/8RYNp5jn101UQK2S6ToBiiHSB40rs6Imy4DJmkTO+v/Ejag/tyS5ClePeE/hFp2P3AMOqdD9AsdSAkPOs5Xyr6TZl8jYY+kCZeJ8M+KfyiefQxkihIqF3Nk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-1fc5296e214so37004485ad.0 for ; Tue, 30 Jul 2024 13:23:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ventanamicro.com; s=google; t=1722371025; x=1722975825; 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=2o5HuuVc4FzZM74XfCFtZwvQxPeOO/S88n6RjapUqbc=; b=l32EVD/bke5M5rru3yy5o0PHAGjACiShji3HpV/jYqphL87YumjcH0WhSwzvLLuQsQ x2Mcu5Tx7M661b46QJWobtaMnSAPknPDfuL10wsLu9orSjGvIvjE3332Rq5GTaRoHSyN 0QFPeNoy4gOD3F2j3hm09p3O6ezlAoxU44ityOwRfivwLLE7AcOjYVfA/mxxF38GsuyU 2OZ8rud4iLXFRip8Nqf/2wi1V/2dBfW8iCfwjNqypckMsBQ/ui4F4a7nVGfG3rU/beNc JmmSYBkoo808HOkErQhNXUQ/kjLACRdTnRtzH5MOgibA/QSJz+yOBwi+LN1Nfw0FhQik jYaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722371025; x=1722975825; 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=2o5HuuVc4FzZM74XfCFtZwvQxPeOO/S88n6RjapUqbc=; b=b5/baEGRZqY1wjSyOi9dfv7630TshFRFW1ep5spAhJ9pp55rwo029yOC48inBc+Cwr WY8Z5n1nxqMZg8ZR7GmXoj5tHzPAGtuHEa++CpeOSMSYe2WYEB5sqWZUktesSnVAYrLI V4gfzhEWzUqC0MOWazDxTsTgBhhSUUTFlfxKdz8sI70EZOrJD7Qcwz9n+KerMo0zjcH8 OJXd3MUDlj0a4kfUXueT7nUqmfEUE8PBUhtRrpVeiBNjoPxVQ6aMb2XCZEGFbMBwnEGH S4FH829LGKy8mSGTN/QRz+3gyn7e65TTa7F1yuu6uEUNO2qabIY2slQASO6jZV6NlclH 4U4Q== X-Gm-Message-State: AOJu0YzYjCiLAg74j1fuDTpaa1QexXWzdjq6ef1oYNJ4XqQOEQUMwopa PRlVO3PNEm9MxpD5je4H3auN48z8Du3Dg4y3qItbDfz1wfnU1o8Dfh7gqgnXZAaEi+KBnquk8PX E2Ts= X-Google-Smtp-Source: AGHT+IHWPaAXb2rD07YefWiBiIhdtWN3voAxucH4Z3y+bpswXlTmrNZYKKRPRyVe0ws//E1K35wXtQ== X-Received: by 2002:a17:902:e54a:b0:1fd:6bfa:f59 with SMTP id d9443c01a7336-1ff0481147cmr159218975ad.19.1722371024726; Tue, 30 Jul 2024 13:23:44 -0700 (PDT) Received: from [172.31.0.109] ([136.36.72.243]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1fed7fccb63sm105837605ad.284.2024.07.30.13.23.43 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Jul 2024 13:23:44 -0700 (PDT) Message-ID: <5685a3c8-e8f3-4106-b747-cd6c5831b44f@ventanamicro.com> Date: Tue, 30 Jul 2024 14:22:55 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Content-Language: en-US From: Jeff Law To: "gcc-patches@gcc.gnu.org" Subject: [RFA][PR rtl-optimization/116136] Fix previously latent SUBREG simplification bug 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 This fixes a testsuite regression seen on m68k after some of the recent ext-dce changes. Ultimately Richard S and I have concluded the bug was a latent issue in subreg simplification. Essentially when simplifying something like (set (target:M1) (subreg:M1 (subreg:M2 (reg:M1) 0) 0)) Where M1 > M2. We'd simplify to: (set (target:M1) (reg:M1)) The problem is on a big endian target that's wrong. Consider if M1 is DI and M2 is SI. The original should extract bits 32..63 from the source register and store them into bits 0..31 of the target register. In the simplified form it's just a copy, so bits 0..63 of the source end up bits 0..63 of the target. This shows up as the following regressions on the m68k: > Tests that now fail, but worked before (3 tests): > > gcc: gcc.c-torture/execute/960416-1.c -O2 execution test > gcc: gcc.c-torture/execute/960416-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test > gcc: gcc.c-torture/execute/960416-1.c -Os execution test The fix is pretty trivial, instead of hardcoding "0" as the byte offset in the test for the simplification, instead we need to use the subreg_lowpart_offset. Anyway, bootstrapped and regression tested on m68k and x86_64 and tested on the other embedded targets as well without regressions. Naturally it fixes the regression noted above. I haven't see other testsuite improvements when I spot checked some of the big endian crosses. OK for the trunk? Jeff PR rtl-optimization/116136 gcc/ * simplify-rtx.cc (simplify_context::simplify_subreg): Check that we're working with the lowpart offset rather than byte 0. diff --git a/gcc/simplify-rtx.cc b/gcc/simplify-rtx.cc index a49eefb34d4..a20a61c5ddd 100644 --- a/gcc/simplify-rtx.cc +++ b/gcc/simplify-rtx.cc @@ -7744,8 +7744,9 @@ simplify_context::simplify_subreg (machine_mode outermode, rtx op, return NULL_RTX; if (outermode == innermostmode - && known_eq (byte, 0U) - && known_eq (SUBREG_BYTE (op), 0)) + && known_eq (byte, subreg_lowpart_offset (outermode, innermode)) + && known_eq (SUBREG_BYTE (op), + subreg_lowpart_offset (innermode, innermostmode))) return SUBREG_REG (op); /* Work out the memory offset of the final OUTERMODE value relative