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
prev parent 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).