public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH 06/11] haifa-sched: Allow for NOTE_INSN_DELETED at start of epilogue
@ 2023-10-17 20:48 Alex Coplan
  2023-10-19 14:54 ` Jeff Law
  0 siblings, 1 reply; 3+ messages in thread
From: Alex Coplan @ 2023-10-17 20:48 UTC (permalink / raw)
  To: gcc-patches
  Cc: Richard Sandiford, Jim Wilson, Michael Meissner, Jeff Law,
	Vladimir Makarov

[-- Attachment #1: Type: text/plain, Size: 603 bytes --]

haifa-sched.cc:remove_notes asserts that it lands on a real (non-note)
insn after advancing past NOTE_INSN_EPILOGUE_BEG, but with the upcoming
post-RA aarch64 load pair pass enabled, we can land on
NOTE_INSN_DELETED.

This patch adjusts remove_notes to remove these if they occur at the
start of the epilogue instead of asserting.

Bootstrapped/regtested as a series on aarch64-linux-gnu, OK for trunk?

gcc/ChangeLog:

	* haifa-sched.cc (remove_notes): Allow for NOTE_INSN_DELETED at
	the start of the epilgoue, remove these.
---
 gcc/haifa-sched.cc | 11 +++++++++++
 1 file changed, 11 insertions(+)


[-- Attachment #2: 0006-haifa-sched-Allow-for-NOTE_INSN_DELETED-at-start-of-.patch --]
[-- Type: text/x-patch, Size: 691 bytes --]

diff --git a/gcc/haifa-sched.cc b/gcc/haifa-sched.cc
index 8e8add709b3..9f45528fbe9 100644
--- a/gcc/haifa-sched.cc
+++ b/gcc/haifa-sched.cc
@@ -4249,6 +4249,17 @@ remove_notes (rtx_insn *head, rtx_insn *tail)
 		  && NOTE_KIND (next) == NOTE_INSN_BASIC_BLOCK
 		  && next != next_tail)
 		next = NEXT_INSN (next);
+
+	      /* Skip over any NOTE_INSN_DELETED at the start of the epilogue.
+	       */
+	      while (NOTE_P (next)
+		     && NOTE_KIND (next) == NOTE_INSN_DELETED)
+		{
+		  auto tmp = NEXT_INSN (next);
+		  delete_insn (next);
+		  next = tmp;
+		}
+
 	      gcc_assert (INSN_P (next));
 	      add_reg_note (next, REG_SAVE_NOTE,
 			    GEN_INT (NOTE_INSN_EPILOGUE_BEG));

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH 06/11] haifa-sched: Allow for NOTE_INSN_DELETED at start of epilogue
  2023-10-17 20:48 [PATCH 06/11] haifa-sched: Allow for NOTE_INSN_DELETED at start of epilogue Alex Coplan
@ 2023-10-19 14:54 ` Jeff Law
  2023-10-19 17:52   ` Alex Coplan
  0 siblings, 1 reply; 3+ messages in thread
From: Jeff Law @ 2023-10-19 14:54 UTC (permalink / raw)
  To: Alex Coplan, gcc-patches
  Cc: Richard Sandiford, Jim Wilson, Michael Meissner, Vladimir Makarov



On 10/17/23 14:48, Alex Coplan wrote:
> haifa-sched.cc:remove_notes asserts that it lands on a real (non-note)
> insn after advancing past NOTE_INSN_EPILOGUE_BEG, but with the upcoming
> post-RA aarch64 load pair pass enabled, we can land on
> NOTE_INSN_DELETED.
> 
> This patch adjusts remove_notes to remove these if they occur at the
> start of the epilogue instead of asserting.
> 
> Bootstrapped/regtested as a series on aarch64-linux-gnu, OK for trunk?
> 
> gcc/ChangeLog:
> 
> 	* haifa-sched.cc (remove_notes): Allow for NOTE_INSN_DELETED at
> 	the start of the epilgoue, remove these.
One could argue that the pass should have actually deleted the insn 
rather than just turned it into a NOTE_INSN_DELETED.  Is there some 
reason that's not done?  A NOTE_INSN_DELETED carries no useful information.


> +	      /* Skip over any NOTE_INSN_DELETED at the start of the epilogue.
> +	       */

Don't bring the close comment down to a new line.  If it fits, but it on 
the last line of the actual comment.  Otherwise bring down part of 
comment so that we don't have the close comment on a line by itself.

Jeff

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH 06/11] haifa-sched: Allow for NOTE_INSN_DELETED at start of epilogue
  2023-10-19 14:54 ` Jeff Law
@ 2023-10-19 17:52   ` Alex Coplan
  0 siblings, 0 replies; 3+ messages in thread
From: Alex Coplan @ 2023-10-19 17:52 UTC (permalink / raw)
  To: Jeff Law
  Cc: gcc-patches, Richard Sandiford, Jim Wilson, Michael Meissner,
	Vladimir Makarov

Hi Jeff,

On 19/10/2023 08:54, Jeff Law wrote:
> 
> 
> On 10/17/23 14:48, Alex Coplan wrote:
> > haifa-sched.cc:remove_notes asserts that it lands on a real (non-note)
> > insn after advancing past NOTE_INSN_EPILOGUE_BEG, but with the upcoming
> > post-RA aarch64 load pair pass enabled, we can land on
> > NOTE_INSN_DELETED.
> > 
> > This patch adjusts remove_notes to remove these if they occur at the
> > start of the epilogue instead of asserting.
> > 
> > Bootstrapped/regtested as a series on aarch64-linux-gnu, OK for trunk?
> > 
> > gcc/ChangeLog:
> > 
> > 	* haifa-sched.cc (remove_notes): Allow for NOTE_INSN_DELETED at
> > 	the start of the epilgoue, remove these.
> One could argue that the pass should have actually deleted the insn rather
> than just turned it into a NOTE_INSN_DELETED.  Is there some reason that's
> not done?  A NOTE_INSN_DELETED carries no useful information.

Yeah, I think we can teach rtl-ssa to do that.  I'm testing a patch to
do so now.  I think the pass is the first consumer of the deletion
functionality (insn_change::DELETE) in rtl-ssa, and I can't see a reason for it
to keep the NOTE_INSN_DELETED around.

So consider the scheduler patch withdrawn for now, thanks!

Alex

> 
> 
> > +	      /* Skip over any NOTE_INSN_DELETED at the start of the epilogue.
> > +	       */
> 
> Don't bring the close comment down to a new line.  If it fits, but it on the
> last line of the actual comment.  Otherwise bring down part of comment so
> that we don't have the close comment on a line by itself.
> 
> Jeff

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2023-10-19 17:52 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-10-17 20:48 [PATCH 06/11] haifa-sched: Allow for NOTE_INSN_DELETED at start of epilogue Alex Coplan
2023-10-19 14:54 ` Jeff Law
2023-10-19 17:52   ` Alex Coplan

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).