From patchwork Tue Jul 16 00:18:41 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Law X-Patchwork-Id: 93954 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id BCB00384AB75 for ; Tue, 16 Jul 2024 00:20:54 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-oo1-xc2e.google.com (mail-oo1-xc2e.google.com [IPv6:2607:f8b0:4864:20::c2e]) by sourceware.org (Postfix) with ESMTPS id D7FA43864C65 for ; Tue, 16 Jul 2024 00:18:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D7FA43864C65 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 D7FA43864C65 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::c2e ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1721089202; cv=none; b=dJ4SpGMurfY+sIgONCPEhmEbJOLdMX4Fqwvq+5Je0nueNZl7+Ee3BfQP7Zqh4UYtppVcJlm3fI8Nrq4Euv1MJDjs41QJkltQAMu/6W9j8XXcY2oGvPH3Ic5wzptis3U83+DerimFWJQIUIj9XsujkpubGI2xoWSmpNZSioRHLmI= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1721089202; c=relaxed/simple; bh=7pYXWcl49/91sJcuudlHChhvHsvf9DylCHt5vvvRa0s=; h=DKIM-Signature:Message-ID:Date:MIME-Version:From:To:Subject; b=LcVHK7gSklQBy7VrRmkbDMIoCf1L8OZa9SUw3+E+AlkOJ5wZPW9u9IJP4ApfldG82qkinc6AEzKb/9HUFLcYjZ6uGKkSXj6sRuRX/TVtPlyun4m4m27KdccVNU/py68WPAOHICoZmA6+yosENL6KRa3ejjRunpa16lO/ZfXHBQ4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-oo1-xc2e.google.com with SMTP id 006d021491bc7-5c694d5c5adso2314833eaf.3 for ; Mon, 15 Jul 2024 17:18:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721089124; x=1721693924; 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=w7V0AZqyL17pjQCAg9cCXdkbd5ek8Zu/Q0n2WAlgwrs=; b=mEjegJyw8ogMDURACvKKvQoCDu0JFaNVCGOYVmgYS1WRQkUWfNUGUMTo2eAZ6jZsGN ESHH/uo87byjLZP9ogipgjQPp2LkFle8JhCi3fDdFIf0TqLxfG8gC/6E7N2+4P1Ghd8r uHtQgKNWOypdzK99heE35BHYdkJ1f0mQ6nunhh5q2bOaw3nvpDjncJksUan5E7a7K4og OfkCfOxh3NuWaCkFoJmK5ymTWgDYWoHOHGYLWjlS0m5j9xmimXKaA02gUr+Ek7SwEliq N6rwjRyTsk1NnISa3XMYRTGg3UVOslmb7TzgLPHhDOPcg3TVHO0VxhApZtq03pE7pzzL qCAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721089124; x=1721693924; 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=w7V0AZqyL17pjQCAg9cCXdkbd5ek8Zu/Q0n2WAlgwrs=; b=ih4oL/KQFBVzB6A3iIDItvzC4VShr4YYGyVZitnXIh16zBCpg1+vkjkG3hkQPBIylC Oi88Y1Uta8TnPz3DVc/IqucGa7GpvdjOrZqFrh/NSDZOdkhN80hQ0XqS1e3+xeXvAwxU V4kk4HQvFS9ciAjGsoNvoMrMI1F7HXx+gAFsXbX9XnYaS6LBMWGzZ25MptsWxo+6UmQE XALX+rIzjB31zwosuQAOcUWWBQ0lCBGw/GN5sIMhxJ+X9yu1w+8voI6v8UTrPz2BS5F7 4pjwm7vgIxGDwBt/NnnDi/mkmpANioxT3yMiKHNp2DobH4ojwOj2rIF2pBm6jOtz38AD VpQg== X-Gm-Message-State: AOJu0YxAnvoqIaY7Azv74WLn3HEybkephuJAIs8KZNnIZ36FqhoTyWSc ScByyABJrVopxlvQLntfvzCWu1VzFtxl1HhABhuKCurGI/CCwrg84nXHFA== X-Google-Smtp-Source: AGHT+IGfjlj/wT9kd0LFYtOchcfSP4sMPOzpksxKA4zrr8cJq+kAP9nlApp+bSE9/bBg+x7d2nrr9w== X-Received: by 2002:a05:6870:4194:b0:25e:4399:56d0 with SMTP id 586e51a60fabf-260bd79bb22mr370417fac.33.1721089124268; Mon, 15 Jul 2024 17:18:44 -0700 (PDT) Received: from [172.31.0.109] ([136.36.72.243]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-260751354fcsm1146717fac.13.2024.07.15.17.18.43 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Jul 2024 17:18:43 -0700 (PDT) Message-ID: <6e02b77e-ff50-44a0-b60c-8094fc32347b@gmail.com> Date: Mon, 15 Jul 2024 18:18:41 -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] Fix liveness computation for shift/rotate counts in ext-dce X-Spam-Status: No, score=-8.4 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 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~patchwork=sourceware.org@gcc.gnu.org So as I've noted before I believe the control flow in ext-dce.cc is horribly messy. While investigating a fix for 115877 I came across another problem related to control flow handling. Specifically, if we have an binary op which implies the 2nd operand is fully live, then we'd actually fail to mark that operand as live. We essentially broke out of the loop which was supposed to be safe. But Y was a REG and if Y is a REG or CONST_INT we skip sub-rtxs and thus failed to process that operand (the shift count) at all. Rather than muck around with control flow, we can just set all the bits as live in DST_MASK and let normal processing continue. With all the bits live IN DST_MASK all the bits implied by the mode of the argument will also be live. No testcase. Bootstrapped and regression tested on x86. Pushing to the trunk. jeff commit b31b8af807f5459674b0b310cb62a5bc81b676e7 Author: Jeff Law Date: Mon Jul 15 18:15:33 2024 -0600 Fix liveness computation for shift/rotate counts in ext-dce So as I've noted before I believe the control flow in ext-dce.cc is horribly messy. While investigating a fix for 115877 I came across another problem related to control flow handling. Specifically, if we have an binary op which implies the 2nd operand is fully live, then we'd actually fail to mark that operand as live. We essentially broke out of the loop which was supposed to be safe. But Y was a REG and if Y is a REG or CONST_INT we skip sub-rtxs and thus failed to process that operand (the shift count) at all. Rather than muck around with control flow, we can just set all the bits as live in DST_MASK and let normal processing continue. With all the bits live IN DST_MASK all the bits implied by the mode of the argument will also be live. No testcase. Bootstrapped and regression tested on x86. Pushing to the trunk. gcc/ * ext-dce.cc (ext_dce_process_uses): Simplify control flow and fix liveness computation for shift/rotate counts. diff --git a/gcc/ext-dce.cc b/gcc/ext-dce.cc index 2869a389c3a..6c961feee63 100644 --- a/gcc/ext-dce.cc +++ b/gcc/ext-dce.cc @@ -632,10 +632,11 @@ ext_dce_process_uses (rtx_insn *insn, rtx obj, bitmap live_tmp) else if (!CONSTANT_P (y)) break; - /* We might have (ashift (const_int 1) (reg...)) */ - /* XXX share this logic with code below. */ + /* We might have (ashift (const_int 1) (reg...)) + By setting dst_mask we can continue iterating on the + the next operand and it will be considered fully live. */ if (binop_implies_op2_fully_live (GET_CODE (src))) - break; + dst_mask = -1; /* If this was anything but a binary operand, break the inner loop. This is conservatively correct as it will cause the