From patchwork Tue Jul 23 03:49:53 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Law X-Patchwork-Id: 94358 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 2E5AF386101A for ; Tue, 23 Jul 2024 03:50:30 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mail-oa1-x30.google.com (mail-oa1-x30.google.com [IPv6:2001:4860:4864:20::30]) by sourceware.org (Postfix) with ESMTPS id 5ED7F3860C34 for ; Tue, 23 Jul 2024 03:49:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5ED7F3860C34 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 5ED7F3860C34 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:4860:4864:20::30 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1721706600; cv=none; b=hPkxeaJQWO9To4Jy9JAauY2oGGMYn2nfDuX2CNvEaaxxBu5CHo6wzgFeckyI7EVGYbESGGQsfZb/CKQQ9jXqNwpoWIqdeJ7WrSz+Phlhw82hpELmitt8o3fa5Lv7UIaDhCSpTJ0qInUgkcGphGqZcVgkDq/MKBKqRFM6e7f5rQk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1721706600; c=relaxed/simple; bh=tt9e2iq0a8VhErELb9WCLrzRfYJssz/EdJoKl9gXMMc=; h=DKIM-Signature:Message-ID:Date:MIME-Version:From:Subject:To; b=Syryair/fWWbPUPviwKwYmU0fspvzo4oeDMsCMD7/9w7MWKhqCVilTv97yHek5FI2wDunY1IL0QYVXmDYwrUWFqmfdYbUslm/NdkGBLZ9WEBZlASFzwHf77kiVV+W3GvsMs85D0UgJDtB3tfqRRwRlRYOraMoKS+Ad+nvU+1U6w= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-oa1-x30.google.com with SMTP id 586e51a60fabf-260e208e126so2964534fac.0 for ; Mon, 22 Jul 2024 20:49:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721706595; x=1722311395; 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=0Hb+KV4eeg6zPrg6O8ot4eeYOTXDAu76N3M5ABTf0ng=; b=Vjo90TiOZti5JvN07oWXQ2Yejf1vH8ib0X7LNnaVHfRJ+zNK4L8j657M3ZCDMVMN5u IMozn7TlWhufNKIrnzD9GDrb0Gjg8n8L4tDdqtckYzQbRgwYF1sV/ctq77iadN9lz5SO MN0gMCAC4P+x1T12fPMGVbYJcL7A2zpeeTFbLVl2JEesq+QhD77b+NTPBuSQ8P3G5Ttm 4cc+DqP/BnpYEwGSZWcTIroL8JpLMGCWP6TO5wAKpZnEu7UlVdbBGMlgEBPdMd2emwYr VwI/qSZ3b/ZHlCCBe8j1BCM2Lk0KZRTfA1EPd8gyUE8eopIHp0C+NJSpJ0CoqCrw9Yd2 cZQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721706595; x=1722311395; 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=0Hb+KV4eeg6zPrg6O8ot4eeYOTXDAu76N3M5ABTf0ng=; b=kkSNDPlQven/8owTXahZuXCCj08YfldAn+B9bhD6xfNVaGT2yvTWgNMfqF9lgSukeZ xIbihLXXRGT2LZTFhf7sJgquWb+7idcErqNE7rP2RscBPS3kxaC6DeKPymKY8qgdQSUx dg9gWAT8Ku58LJY+g9ZZFg24JTQurm70mif7o5PXp4cfdvE1rVqexwWCKD/I8amiQFxF ofyozm8jvo1e5yLmauTfAfdGKjitJo/BGMCySEU0xrhg/c6njeKy/0XqBdel0t88JRQc ZIMB22KFlEkHwLN7wPXBcuztV5myF3FGPEPJm1qES9Xp0MfKi0+vah0vloOIEhgcENkO ryig== X-Gm-Message-State: AOJu0Yy4XqOl3e0B32HGSB1rPw/D6j5VOunCURHxY236weYRvHWbJSMQ f3pV3IGH1hT41ewChBlXqeJuJUbsGy54i/HKpBtWn6KUsGoaluoINiH8eQ== X-Google-Smtp-Source: AGHT+IH+mVPTVyIZzS20HELlyHoHJV9Dsdm4MwBPmYvV3U+dx0nHutY9vbPav/TSAs21Ri5slZlrDQ== X-Received: by 2002:a05:6871:80e:b0:261:1267:fe95 with SMTP id 586e51a60fabf-264690938d6mr1574175fac.9.1721706595129; Mon, 22 Jul 2024 20:49:55 -0700 (PDT) Received: from [172.31.0.109] ([136.36.72.243]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-2610cb15b7asm2001913fac.53.2024.07.22.20.49.54 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 22 Jul 2024 20:49:54 -0700 (PDT) Message-ID: Date: Mon, 22 Jul 2024 21:49:53 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Beta Content-Language: en-US From: Jeff Law Subject: [committed][5/n][PR rtl-optimization/115877] Fix handling of input/output operands To: "gcc-patches@gcc.gnu.org" 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 in this patch we're correcting a failure to mark objects live in scenarios like (set (dest) (plus (dest) (src)) When handling set pseudos, we transfer the liveness information from LIVENOW into LIVE_TMP. LIVE_TMP is subsequently used to narrow what bit groups are live for the inputs. The first time we process the block we may not have DEST in the LIVENOW set (it may be live across the loop, but not live after the loop). Thus we can totally miss making certain objects live, resulting in incorrect code. The fix is pretty simple. If LIVE_TMP is empty, then we should go ahead and mark all the bit groups for the set object in LIVE_TMP. This also removes an invalid gcc_assert on the state of the liveness bitmaps. This showed up on pru, rl78 and/or msp430 in the testsuite. So no new test. Bootstrapped and regression tested on x86_64 and also run through my tester on all the cross platforms. Pushing to the trunk. jeff commit ad642d2c950657539777ea436b787e7fff4ec09e Author: Jeff Law Date: Mon Jul 22 21:48:28 2024 -0600 [5/n][PR rtl-optimization/115877] Fix handling of input/output operands So in this patch we're correcting a failure to mark objects live in scenarios like (set (dest) (plus (dest) (src)) When handling set pseudos, we transfer the liveness information from LIVENOW into LIVE_TMP. LIVE_TMP is subsequently used to narrow what bit groups are live for the inputs. The first time we process the block we may not have DEST in the LIVENOW set (it may be live across the loop, but not live after the loop). Thus we can totally miss making certain objects live, resulting in incorrect code. The fix is pretty simple. If LIVE_TMP is empty, then we should go ahead and mark all the bit groups for the set object in LIVE_TMP. This also removes an invalid gcc_assert on the state of the liveness bitmaps. This showed up on pru, rl78 and/or msp430 in the testsuite. So no new test. Bootstrapped and regression tested on x86_64 and also run through my tester on all the cross platforms. Pushing to the trunk. PR rtl-optimization/115877 gcc/ * ext-dce.cc (ext_dce_process_sets): Reasonably handle input/output operands. (ext_dce_rd_transfer_n): Drop bogus assertion. diff --git a/gcc/ext-dce.cc b/gcc/ext-dce.cc index 21feabd9ce3..c56dfb505b8 100644 --- a/gcc/ext-dce.cc +++ b/gcc/ext-dce.cc @@ -245,13 +245,25 @@ ext_dce_process_sets (rtx_insn *insn, rtx obj, bitmap live_tmp) continue; } - /* Transfer all the LIVENOW bits for X into LIVE_TMP. */ + /* LIVE_TMP contains the set groups that are live-out and set in + this insn. It is used to narrow the groups live-in for the + inputs of this insn. + + The simple thing to do is mark all the groups as live, but + that will significantly inhibit optimization. + + We also need to be careful in the case where we have an in-out + operand. If we're not careful we'd clear LIVE_TMP + incorrectly. */ HOST_WIDE_INT rn = REGNO (SUBREG_REG (x)); int limit = group_limit (SUBREG_REG (x)); for (HOST_WIDE_INT i = 4 * rn; i < 4 * rn + limit; i++) if (bitmap_bit_p (livenow, i)) bitmap_set_bit (live_tmp, i); + if (bitmap_empty_p (live_tmp)) + make_reg_live (live_tmp, rn); + /* The mode of the SUBREG tells us how many bits we can clear. */ machine_mode mode = GET_MODE (x); @@ -316,14 +328,25 @@ ext_dce_process_sets (rtx_insn *insn, rtx obj, bitmap live_tmp) /* Now handle the actual object that was changed. */ if (REG_P (x)) { - /* Transfer the appropriate bits from LIVENOW into - LIVE_TMP. */ + /* LIVE_TMP contains the set groups that are live-out and set in + this insn. It is used to narrow the groups live-in for the + inputs of this insn. + + The simple thing to do is mark all the groups as live, but + that will significantly inhibit optimization. + + We also need to be careful in the case where we have an in-out + operand. If we're not careful we'd clear LIVE_TMP + incorrectly. */ HOST_WIDE_INT rn = REGNO (x); int limit = group_limit (x); for (HOST_WIDE_INT i = 4 * rn; i < 4 * rn + limit; i++) if (bitmap_bit_p (livenow, i)) bitmap_set_bit (live_tmp, i); + if (bitmap_empty_p (live_tmp)) + make_reg_live (live_tmp, rn); + /* Now clear the bits known written by this instruction. Note that BIT need not be a power of two, consider a ZERO_EXTRACT destination. */ @@ -935,8 +958,6 @@ ext_dce_rd_transfer_n (int bb_index) the generic dataflow code that something changed. */ if (!bitmap_equal_p (&livein[bb_index], livenow)) { - gcc_assert (!bitmap_intersect_compl_p (&livein[bb_index], livenow)); - bitmap_copy (&livein[bb_index], livenow); return true; }