public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jeff Law <jeffreyalaw@gmail.com>
To: Jeff Law via Gcc-patches <gcc-patches@gcc.gnu.org>,
	richard.sandiford@arm.com
Subject: Re: [PATCH] Allow prologues and epilogues to be inserted later
Date: Fri, 18 Nov 2022 09:42:41 -0700	[thread overview]
Message-ID: <f7b5712d-6797-de98-e47d-48a3de42f3d6@gmail.com> (raw)
In-Reply-To: <mpta64ocmuq.fsf@arm.com>


On 11/18/22 08:18, Richard Sandiford wrote:
>
> Yeah, good point.  How does the version below look?  Tested as before.
>
> I guess it's a philosophical question what distinguishes "late compilation"
> from everything else, but I think it makes sense for it to mean "no code
> motion" (among other things).  And it's useful if targets have a well-
> defined point at which they can insert their own passes while guaranteeing
> that:
>
> - the CFG still exists and hasn't lost information
> - no code motion occurs later
> - alignments aren't nailed down yet
> - variable tracking occurs later (and so will account for whatever the
>    target does in its pass)

Seems like a reasonable set of properties.  Do we want to document this 
somewhere so that it get captured?  That can be independent of this 
particular patch.


>
> I don't think it's controversial to say that delay-branch reorg should
> happen as part of normal scheduling, with the later passes coping with
> the SEQUENCEs generated from it, but there's no realistic chance of
> that happening.  So unfortunately it's always likely to be a special
> case...

I've been wanting the guts of dbr moved into sched2 for a long time.  
I've speculated that we could use the dependence analysis from sched2 to 
provide the candidates for delay slot filling and that doing so would 
probably pick up the vast majority of opportunities, but without the 
ad-hoc dependency bits in reorg.c. But yea, realistically nobody's going 
to invest the time to revamp reorg.


>
> Bernd did some nice work on avoiding dbr for bfin (IIRC), but without
> the handling of SEQUENCEs in rtl passes, even that version had to
> happen during md_reorg.

Never really looked at it.



>
> Thanks,
> Richard
>
>
> gcc/
> 	* target.def (use_late_prologue_epilogue): New hook.
> 	* doc/tm.texi.in: Add TARGET_USE_LATE_PROLOGUE_EPILOGUE.
> 	* doc/tm.texi: Regenerate.
> 	* passes.def (pass_late_thread_prologue_and_epilogue): New pass.
> 	* tree-pass.h (make_pass_late_thread_prologue_and_epilogue): Declare.
> 	* function.cc (pass_thread_prologue_and_epilogue::gate): New function.
> 	(pass_data_late_thread_prologue_and_epilogue): New pass variable.
> 	(pass_late_thread_prologue_and_epilogue): New pass class.
> 	(make_pass_late_thread_prologue_and_epilogue): New function.

OK

jeff



      reply	other threads:[~2022-11-18 16:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-11 16:21 Richard Sandiford
2022-11-15 17:57 ` Jeff Law
2022-11-18 15:18   ` Richard Sandiford
2022-11-18 16:42     ` Jeff Law [this message]

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=f7b5712d-6797-de98-e47d-48a3de42f3d6@gmail.com \
    --to=jeffreyalaw@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=richard.sandiford@arm.com \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).