public inbox for gentoo-commits@lists.gentoo.org
 help / color / mirror / Atom feed
From: "Sam James" <sam@gentoo.org>
To: gentoo-commits@lists.gentoo.org
Subject: [gentoo-commits] proj/gcc-patches:master commit in: 15.0.0/gentoo/
Date: Fri, 21 Mar 2025 19:31:48 +0000 (UTC)	[thread overview]
Message-ID: <1742585499.5c804b8430a3758731aa1ea866b86b4390d0bb57.sam@gentoo> (raw)

commit:     5c804b8430a3758731aa1ea866b86b4390d0bb57
Author:     Sam James <sam <AT> gentoo <DOT> org>
AuthorDate: Fri Mar 21 19:31:39 2025 +0000
Commit:     Sam James <sam <AT> gentoo <DOT> org>
CommitDate: Fri Mar 21 19:31:39 2025 +0000
URL:        https://gitweb.gentoo.org/proj/gcc-patches.git/commit/?id=5c804b84

15.0.0: drop upstream LRA patch

Just merged.

Signed-off-by: Sam James <sam <AT> gentoo.org>

 15.0.0/gentoo/78_all_PR118615.patch | 244 ------------------------------------
 15.0.0/gentoo/README.history        |   1 -
 2 files changed, 245 deletions(-)

diff --git a/15.0.0/gentoo/78_all_PR118615.patch b/15.0.0/gentoo/78_all_PR118615.patch
deleted file mode 100644
index bea0c22..0000000
--- a/15.0.0/gentoo/78_all_PR118615.patch
+++ /dev/null
@@ -1,244 +0,0 @@
-https://inbox.sourceware.org/gcc-patches/Z91i4oSOe2t9Wsu5@tucnak/
-
-Date: Fri, 21 Mar 2025 14:00:18 +0100
-From: Jakub Jelinek <jakub@redhat.com>
-To: Vladimir Makarov <vmakarov@redhat.com>, Jeff Law <jeffreyalaw@gmail.com>,
-        Richard Sandiford <richard.sandiford@arm.com>
-Cc: gcc-patches@gcc.gnu.org, Surya Kumari Jangala <jskumari@linux.ibm.com>,
-        Peter Bergner <bergner@linux.ibm.com>
-Subject: [PATCH] lra, v2: emit caller-save register spills before call insn
- [PR116028]
-Message-ID: <Z91i4oSOe2t9Wsu5@tucnak>
-Reply-To: Jakub Jelinek <jakub@redhat.com>
-MIME-Version: 1.0
-X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12
-X-Mimecast-Spam-Score: 0
-X-Mimecast-MFC-PROC-ID: _tXP__7Gkm9pvYzp53m4LpOJ23nLH9dr5dUlzvuS5ts_1742562026
-X-Mimecast-Originator: redhat.com
-Content-Type: text/plain; charset=us-ascii
-Content-Disposition: inline
-X-Spam-Status: No, score=-13.6 required=5.0 tests=BAYES_00,DKIM_INVALID,DKIM_SIGNED,KAM_DMARC_QUARANTINE,KAM_DMARC_STATUS,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_W,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6
-X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
-List-Id: <gcc-patches.gcc.gnu.org>
-
-Hi!
-
-Here is an updated version of Surya's PR116028 fix from August, which got
-reverted because it caused bootstrap failures on aarch64, later on bootstrap
-comparison errors there as well and problems on other targets as well.
-
-The changes compared to the
-https://gcc.gnu.org/pipermail/gcc-patches/2024-August/658973.html
-version are:
-1) the reason for aarch64 miscompilations and later on bootstrap comparison
-   issues as can be seen on the pr118615.c testcase in the patch was that
-   when curr_insn is a JUMP_INSN or some cases of CALL_INSNs,
-   split_if_necessary is called with before_p true and if it is successful,
-   the code set use_insn = PREV_INSN (curr_insn); instead of use_insn =
-   curr_insn; and that use_insn is then what is passed to
-   add_next_usage_insn; now, if the patch decides to emit the save
-   instruction(s) before the first call after curr_insn in the ebb rather
-   than before the JUMP_INSN/CALL_INSN, PREV_INSN (curr_insn) is some random
-   insn before it, not anything related to the split_reg actions.
-   If it is e.g. a DEBUG_INSN in one case vs. some unrelated other insn
-   otherwise, that can affect further split_reg within the same function
-2) as suggested by Surya in PR118615, it makes no sense to try to change
-   behavior if the first call after curr_insn is in the same bb as curr_insn
-3) split_reg is actually called sometimes from within inherit_in_ebb but
-   sometimes from elsewhere; trying to use whatever last call to
-   inherit_in_ebb saw last is a sure way to run into wrong-code issues,
-   so instead of clearing the rtx var at the start of inherit_in_ebb it is
-   now cleared at the end of it
-4) calling the var latest_call_insn was weird, inherit_in_ebb walks the ebb
-   backwards, so what the var contains is the first call insn within the
-   ebb (after curr_insn)
-5) the patch was using
-   lra_process_new_insns (PREV_INSN (latest_call_insn), NULL, save,
-                          "Add save<-reg");
-   to emit the save insn before latest_call_insn.  That feels quite weird
-   given that latest_call_insn has explicit support for adding stuff
-   before some insn or after some insn, adding something before some
-   insn doesn't really need to be done as addition after PREV_INSN
-6) some formatting nits + new testcase + removal of xfail even on arm32
-
-Bootstrapped/regtested on x86_64-linux/i686-linux (my usual
---enable-checking=yes,rtl,extra builds), aarch64-linux (normal default
-bootstrap) and our distro scratch build
-({x86_64,i686,aarch64,powerpc64le,s390x}-linux --enable-checking=release
-LTO profiledbootstrap/regtest), I think Sam James tested on 32-bit arm
-too.
-On aarch64-linux this results in
--FAIL: gcc.dg/pr10474.c scan-rtl-dump pro_and_epilogue "Performing shrink-wrapping"
-
-I admit I don't know the code well nor understood everything it is doing.
-
-I have some concerns:
-1) I wonder if there is a guarantee that first_call_insn if non-NULL will be
-   always in between curr_insn and usage_insn when call_save_p; I'd hope
-   yes because if usage_insn is before first_call_insn in the ebb,
-   presumably it wouldn't need to find call save regs because the range
-   wouldn't cross any calls
-2) I wonder whether it wouldn't be better instead of inserting the saves
-   before first_call_insn insert it at the start of the bb containing that
-   call (after labels of course); emitting it right before a call could
-   mislead code looking for argument slot initialization of the call
-3) even when avoiding the use_insn = PREV_INSN (curr_insn);, I wonder
-   if it is ok to use use_insn equal to curr_insn rather than the insns
-   far later where we actually inserted it, but primarily because I don't
-   understand the code much; I think for the !before_p case it is doing
-   similar thing  on a shorter distance, the saves were emitted after
-   curr_insn and we record it on curr_insn
-
-2025-03-21  Surya Kumari Jangala  <jskumari@linux.ibm.com>
-	    Jakub Jelinek  <jakub@redhat.com>
-
-	PR rtl-optimization/116028
-	PR rtl-optimization/118615
-	* lra-constraints.cc (first_call_insn): New variable.
-	(split_reg): Spill register before first_call_insn if call_save_p
-	and the call is in a different bb in the ebb.
-	(split_if_necessary): Formatting fix.
-	(inherit_in_ebb): Set first_call_insn when handling a CALL_INSN.
-	For successful split_if_necessary with before_p, only change
-	use_insn if it emitted any new instructions before curr_insn.
-	Clear first_call_insn before returning.
-	
-	* gcc.dg/ira-shrinkwrap-prep-1.c: Remove xfail for powerpc.
-	* gcc.dg/pr10474.c: Remove xfail for powerpc and arm.
-	* gcc.dg/pr118615.c: New test.
-
---- a/gcc/lra-constraints.cc	2025-03-19 19:20:41.644440691 +0100
-+++ b/gcc/lra-constraints.cc	2025-03-20 18:40:04.188299643 +0100
-@@ -152,6 +152,9 @@ static machine_mode curr_operand_mode[MA
-    (e.g. constant) and whose subreg is given operand of the current
-    insn.  VOIDmode in all other cases.  */
- static machine_mode original_subreg_reg_mode[MAX_RECOG_OPERANDS];
-+/* The first call insn after curr_insn within the EBB during inherit_in_ebb
-+   or NULL outside of that function.  */
-+static rtx_insn *first_call_insn;
- 
- \f
- 
-@@ -6373,12 +6376,26 @@ split_reg (bool before_p, int original_r
-   lra_process_new_insns (as_a <rtx_insn *> (usage_insn),
- 			 after_p ? NULL : restore,
- 			 after_p ? restore : NULL,
--			 call_save_p
--			 ?  "Add reg<-save" : "Add reg<-split");
--  lra_process_new_insns (insn, before_p ? save : NULL,
--			 before_p ? NULL : save,
--			 call_save_p
--			 ?  "Add save<-reg" : "Add split<-reg");
-+			 call_save_p ? "Add reg<-save" : "Add reg<-split");
-+  if (call_save_p
-+      && first_call_insn != NULL
-+      && BLOCK_FOR_INSN (first_call_insn) != BLOCK_FOR_INSN (insn))
-+    /* PR116028: If original_regno is a pseudo that has been assigned a
-+       call-save hard register, then emit the spill insn before the call
-+       insn 'first_call_insn' instead of adjacent to 'insn'.  If 'insn'
-+       and 'first_call_insn' belong to the same EBB but to two separate
-+       BBs, and if 'insn' is present in the entry BB, then generating the
-+       spill insn in the entry BB can prevent shrink wrap from happening.
-+       This is because the spill insn references the stack pointer and
-+       hence the prolog gets generated in the entry BB itself.  It is
-+       also more efficient to generate the spill before
-+       'first_call_insn' as the spill now occurs only in the path
-+       containing the call.  */
-+    lra_process_new_insns (first_call_insn, save, NULL, "Add save<-reg");
-+  else
-+    lra_process_new_insns (insn, before_p ? save : NULL,
-+			   before_p ? NULL : save,
-+			   call_save_p ? "Add save<-reg" : "Add split<-reg");
-   if (nregs > 1 || original_regno < FIRST_PSEUDO_REGISTER)
-     /* If we are trying to split multi-register.  We should check
-        conflicts on the next assignment sub-pass.  IRA can allocate on
-@@ -6484,7 +6501,7 @@ split_if_necessary (int regno, machine_m
- 		&& (INSN_UID (XEXP (next_usage_insns, 0)) < max_uid)))
- 	&& need_for_split_p (potential_reload_hard_regs, regno + i)
- 	&& split_reg (before_p, regno + i, insn, next_usage_insns, NULL))
--    res = true;
-+      res = true;
-   return res;
- }
- 
-@@ -7074,6 +7092,7 @@ inherit_in_ebb (rtx_insn *head, rtx_insn
- 	      last_call_for_abi[callee_abi.id ()] = calls_num;
- 	      full_and_partial_call_clobbers
- 		|= callee_abi.full_and_partial_reg_clobbers ();
-+	      first_call_insn = curr_insn;
- 	      if ((cheap = find_reg_note (curr_insn,
- 					  REG_RETURNED, NULL_RTX)) != NULL_RTX
- 		  && ((cheap = XEXP (cheap, 0)), true)
-@@ -7142,6 +7161,7 @@ inherit_in_ebb (rtx_insn *head, rtx_insn
- 		    {
- 		      bool before_p;
- 		      rtx_insn *use_insn = curr_insn;
-+		      rtx_insn *prev_insn = PREV_INSN (curr_insn);
- 
- 		      before_p = (JUMP_P (curr_insn)
- 				  || (CALL_P (curr_insn) && reg->type == OP_IN));
-@@ -7156,7 +7176,7 @@ inherit_in_ebb (rtx_insn *head, rtx_insn
- 			  change_p = true;
- 			  /* Invalidate. */
- 			  usage_insns[src_regno].check = 0;
--			  if (before_p)
-+			  if (before_p && PREV_INSN (curr_insn) != prev_insn)
- 			    use_insn = PREV_INSN (curr_insn);
- 			}
- 		      if (NONDEBUG_INSN_P (curr_insn))
-@@ -7278,6 +7298,7 @@ inherit_in_ebb (rtx_insn *head, rtx_insn
- 	    }
- 	}
-     }
-+  first_call_insn = NULL;
-   return change_p;
- }
- 
---- a/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-1.c	2024-07-01 11:28:23.278230620 +0200
-+++ b/gcc/testsuite/gcc.dg/ira-shrinkwrap-prep-1.c	2025-03-20 19:50:49.369486995 +0100
-@@ -26,4 +26,4 @@ bar (long a)
- 
- /* { dg-final { scan-rtl-dump "Will split live ranges of parameters" "ira" } } */
- /* { dg-final { scan-rtl-dump "Split live-range of register" "ira" { xfail { ! aarch64*-*-* } } } } */
--/* { dg-final { scan-rtl-dump "Performing shrink-wrapping" "pro_and_epilogue" { xfail powerpc*-*-* } } } */
-+/* { dg-final { scan-rtl-dump "Performing shrink-wrapping" "pro_and_epilogue" } } */
---- a/gcc/testsuite/gcc.dg/pr10474.c	2025-03-20 19:50:49.379486857 +0100
-+++ b/gcc/testsuite/gcc.dg/pr10474.c	2025-03-21 09:33:23.808051052 +0100
-@@ -12,5 +12,4 @@ void f(int *i)
- 	}
- }
- 
--/* XFAIL due to PR70681.  */ 
--/* { dg-final { scan-rtl-dump "Performing shrink-wrapping" "pro_and_epilogue"  { xfail arm*-*-* powerpc*-*-* } } } */
-+/* { dg-final { scan-rtl-dump "Performing shrink-wrapping" "pro_and_epilogue" } } */
---- a/gcc/testsuite/gcc.dg/pr118615.c	2025-03-21 09:44:26.502876412 +0100
-+++ b/gcc/testsuite/gcc.dg/pr118615.c	2025-03-21 09:45:22.447104189 +0100
-@@ -0,0 +1,24 @@
-+/* PR rtl-optimization/118615 */
-+/* { dg-do compile { target scheduling } } */
-+/* { dg-options "-O2 -fcompare-debug -fschedule-insns" } */
-+
-+void foo (void);
-+void bar (int);
-+void baz (int *);
-+int j;
-+
-+void
-+qux (int k, int *m)
-+{
-+  int n;
-+  if (k)
-+    {
-+      foo ();
-+      if (m)
-+	{
-+	  bar (j);
-+	  baz (m);
-+	}
-+    }
-+  baz (&n);
-+}
-
-	Jakub
-
-

diff --git a/15.0.0/gentoo/README.history b/15.0.0/gentoo/README.history
index 5543b1c..f301994 100644
--- a/15.0.0/gentoo/README.history
+++ b/15.0.0/gentoo/README.history
@@ -1,6 +1,5 @@
 48	????
 
-	+ 78_all_PR118615.patch
 	+ 79_all_PR117811-arm-neon-shift.patch
 
 47	16 March 2025


             reply	other threads:[~2025-03-21 19:31 UTC|newest]

Thread overview: 183+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-21 19:31 Sam James [this message]
  -- strict thread matches above, loose matches on Subject: below --
2025-03-25 10:27 [gentoo-commits] proj/gcc-patches:master commit in: 15.0.0/gentoo/ Sam James
2025-03-25  8:38 Sam James
2025-03-25  2:32 Sam James
2025-03-25  1:27 Sam James
2025-03-24  0:35 Sam James
2025-03-21 17:21 Sam James
2025-03-21 16:23 Sam James
2025-03-21 11:20 Sam James
2025-03-21  8:51 Sam James
2025-03-21  6:07 Sam James
2025-03-20 22:08 Sam James
2025-03-20  1:59 Sam James
2025-03-20  1:59 Sam James
2025-03-16 22:37 Sam James
2025-03-14 14:46 Sam James
2025-03-14 13:37 Sam James
2025-03-13 16:48 Sam James
2025-03-13 10:08 Sam James
2025-03-11 10:32 Sam James
2025-03-07 16:54 Sam James
2025-03-03 16:38 Sam James
2025-03-01 10:33 Sam James
2025-03-01  6:50 Sam James
2025-02-17  1:30 Sam James
2025-02-13  9:23 Sam James
2025-02-12 15:12 Sam James
2025-02-10 21:22 Sam James
2025-02-09 23:58 Sam James
2025-02-07 23:37 Sam James
2025-02-07 21:19 Sam James
2025-02-03 22:04 Sam James
2025-02-02 22:41 Sam James
2025-01-29 20:21 Sam James
2025-01-26 22:52 Sam James
2025-01-22 16:27 Sam James
2025-01-19 22:43 Sam James
2025-01-16 23:11 Sam James
2025-01-16 23:11 Sam James
2025-01-15 11:41 Sam James
2025-01-14 16:22 Sam James
2025-01-14 15:06 Sam James
2025-01-14 15:06 Sam James
2025-01-14 12:29 Sam James
2025-01-14  8:43 Sam James
2025-01-14  8:40 Sam James
2025-01-13 13:58 Sam James
2025-01-13  6:00 Sam James
2025-01-13  3:40 Sam James
2025-01-13  3:23 Sam James
2025-01-13  3:20 Sam James
2025-01-13  0:20 Sam James
2025-01-12 18:53 Sam James
2025-01-11 12:53 Sam James
2025-01-08 21:51 Sam James
2025-01-06 10:50 Sam James
2025-01-06 10:03 Sam James
2025-01-06  4:49 Sam James
2025-01-06  4:44 Sam James
2025-01-06  4:13 Sam James
2025-01-06  4:13 Sam James
2025-01-06  4:13 Sam James
2025-01-06  4:03 Sam James
2025-01-05 23:19 Sam James
2025-01-03  3:07 Sam James
2024-12-30  1:05 Sam James
2024-12-29 10:00 Sam James
2024-12-27 15:14 Sam James
2024-12-24 20:48 Sam James
2024-12-22 22:46 Sam James
2024-12-20 11:25 Sam James
2024-12-20  5:57 Sam James
2024-12-20  1:55 Sam James
2024-12-19 18:34 Sam James
2024-12-13 13:23 Sam James
2024-12-13 11:52 Sam James
2024-12-13  5:08 Sam James
2024-12-12 12:28 Sam James
2024-12-11  4:41 Sam James
2024-12-11  0:58 Sam James
2024-12-10 19:19 Sam James
2024-12-10 14:55 Sam James
2024-12-10  5:19 Sam James
2024-12-10  5:13 Sam James
2024-12-10  5:11 Sam James
2024-12-10  5:07 Sam James
2024-12-09  3:05 Sam James
2024-12-08 22:41 Sam James
2024-12-06 17:33 Sam James
2024-12-04 20:40 Sam James
2024-12-01 22:51 Sam James
2024-12-01 22:51 Sam James
2024-11-30 11:30 Sam James
2024-11-27 17:42 Sam James
2024-11-25 15:10 Sam James
2024-11-25  3:01 Sam James
2024-11-25  3:00 Sam James
2024-11-25  3:00 Sam James
2024-11-24 22:42 Sam James
2024-11-18 17:25 Sam James
2024-11-18 10:42 Sam James
2024-11-18 10:42 Sam James
2024-11-18  9:25 Sam James
2024-11-18  9:25 Sam James
2024-11-14 18:38 Sam James
2024-11-13  4:26 Sam James
2024-11-13  0:16 Sam James
2024-11-12  2:33 Sam James
2024-11-11 19:46 Sam James
2024-11-11 19:46 Sam James
2024-11-10 22:41 Sam James
2024-11-09 16:24 Sam James
2024-11-09  7:55 Sam James
2024-11-08  8:22 Sam James
2024-11-07 16:13 Sam James
2024-11-03 23:16 Sam James
2024-11-01  8:24 Sam James
2024-11-01  8:24 Sam James
2024-11-01  8:18 Sam James
2024-11-01  8:17 Sam James
2024-10-30 16:03 Sam James
2024-10-29 19:17 Sam James
2024-10-28 21:32 Sam James
2024-10-28  8:09 Sam James
2024-10-23 15:40 Sam James
2024-10-22 19:09 Sam James
2024-10-22 18:34 Sam James
2024-10-21 12:33 Sam James
2024-10-21 12:27 Sam James
2024-10-21 12:26 Sam James
2024-10-21 11:45 Sam James
2024-10-20 22:42 Sam James
2024-10-18 14:05 Sam James
2024-10-18 10:35 Sam James
2024-10-17 23:33 Sam James
2024-10-17 23:03 Sam James
2024-10-17  5:01 Sam James
2024-10-17  4:15 Sam James
2024-10-13 22:48 Sam James
2024-10-07  2:45 Sam James
2024-10-04 10:37 Sam James
2024-10-04  9:28 Sam James
2024-10-02 19:45 Sam James
2024-09-30 14:05 Sam James
2024-09-29 22:56 Sam James
2024-09-24  1:41 Sam James
2024-09-23 15:23 Sam James
2024-09-02  2:28 Sam James
2024-08-26 13:44 Sam James
2024-08-26  6:24 Sam James
2024-08-23 13:51 Sam James
2024-08-20 20:31 Sam James
2024-08-19 18:43 Sam James
2024-08-14  9:48 Sam James
2024-08-14  2:57 Sam James
2024-08-11 22:40 Sam James
2024-08-09 19:54 Sam James
2024-08-09 19:54 Sam James
2024-08-09 19:47 Sam James
2024-08-09 19:25 Sam James
2024-08-08 11:10 Sam James
2024-08-08 11:06 Sam James
2024-08-08 11:03 Sam James
2024-08-05  9:09 Sam James
2024-08-05  1:54 Sam James
2024-08-05  1:51 Sam James
2024-08-02 20:39 Sam James
2024-08-01 14:40 Sam James
2024-07-28 23:34 Sam James
2024-07-22  1:11 Sam James
2024-07-19 11:14 Sam James
2024-07-18  0:45 Sam James
2024-07-14 23:36 Sam James
2024-06-28 12:49 Sam James
2024-06-27  0:02 Sam James
2024-06-26 23:57 Sam James
2024-06-16 22:45 Sam James
2024-06-10 20:18 Sam James
2024-06-10 17:28 Sam James
2024-06-10 17:28 Sam James
2024-06-10  2:08 Sam James
2024-06-08 17:03 Sam James
2024-06-08 17:03 Sam James

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1742585499.5c804b8430a3758731aa1ea866b86b4390d0bb57.sam@gentoo \
    --to=sam@gentoo.org \
    --cc=gentoo-commits@lists.gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox