Re: [PATCH] Allow prologues and epilogues to be inserted later
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
Re: [PATCH] Allow prologues and epilogues to be inserted later
Jeff Law via Gcc-patches writes: > On 11/11/22 09:21, Richard Sandiford via Gcc-patches wrote: >> Arm's SME adds a new processor mode called streaming mode. >> This mode enables some new (matrix-oriented) instructions and >> disables several existing groups of instructions, such as most >> Advanced SIMD vector instructions and a much smaller set of SVE >> instructions. It can also change the current vector length. >> >> There are instructions to switch in and out of streaming mode. >> However, their effect on the ISA and vector length can't be represented >> directly in RTL, so they need to be emitted late in the pass pipeline, >> close to md_reorg. >> >> It's sometimes the responsibility of the prologue and epilogue to >> switch modes, which means we need to emit the prologue and epilogue >> sequences late as well. (This loses shrink-wrapping and scheduling >> opportunities, but that's a price worth paying.) >> >> This patch therefore adds a target hook for forcing prologue >> and epilogue insertion to happen later in the pipeline. >> >> Tested on aarch64-linux-gnu (including with a follow-on patch) >> and x86_64-linux-gnu. OK to install? >> I'll ob >> Richard >> >> >> gcc/ >> * target.def (use_late_prologue_epilogue): New hook. >> * doc/gccint/target-macros/miscellaneous-parameters.rst: Add >> TARGET_USE_LATE_PROLOGUE_EPILOGUE. >> * doc/gccint/target-macros/tm.rst.in: 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. > > I'm not sure how we'll enforce the no target independent code motion > limitation that this seems to need and the exception made for reorg is > hackish in that it appears we just rely on the fact that reorg isn't run > for the one target where this matters. That does make me wonder if we > should future proof this ever so slightly -- is there a reasonably easy > way to fail if a target were to define delay slots and the need for late > prologue/epilogue? If so, that seems advisable. > > > No objection to the meat of the patch, just wondering a bit about the > additional sanity checking we can do... 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) One of the SME patches uses it for that purpose, independently of this patch, and also needs there to be no code motion. 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... 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. 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. --- gcc/doc/tm.texi| 19 ++ gcc/doc/tm.texi.in | 2 ++ gcc/function.cc| 49 ++ gcc/passes.def | 3 +++ gcc/target.def | 21 gcc/tree-pass.h| 2 ++ 6 files changed, 96 insertions(+) diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi index af77d16030c..6624768d68c 100644 --- a/gcc/doc/tm.texi +++ b/gcc/doc/tm.texi @@ -11667,6 +11667,25 @@ of the if-block in the @code{struct ce_if_block} structure that is pointed to by @var{ce_info}. @end defmac +@deftypefn {Target Hook} bool TARGET_USE_LATE_PROLOGUE_EPILOGUE () +Return true if the current function's prologue and epilogue should +be emitted late in the pass
Re: [PATCH] Allow prologues and epilogues to be inserted later
On 11/11/22 09:21, Richard Sandiford via Gcc-patches wrote: Arm's SME adds a new processor mode called streaming mode. This mode enables some new (matrix-oriented) instructions and disables several existing groups of instructions, such as most Advanced SIMD vector instructions and a much smaller set of SVE instructions. It can also change the current vector length. There are instructions to switch in and out of streaming mode. However, their effect on the ISA and vector length can't be represented directly in RTL, so they need to be emitted late in the pass pipeline, close to md_reorg. It's sometimes the responsibility of the prologue and epilogue to switch modes, which means we need to emit the prologue and epilogue sequences late as well. (This loses shrink-wrapping and scheduling opportunities, but that's a price worth paying.) This patch therefore adds a target hook for forcing prologue and epilogue insertion to happen later in the pipeline. Tested on aarch64-linux-gnu (including with a follow-on patch) and x86_64-linux-gnu. OK to install? I'll ob Richard gcc/ * target.def (use_late_prologue_epilogue): New hook. * doc/gccint/target-macros/miscellaneous-parameters.rst: Add TARGET_USE_LATE_PROLOGUE_EPILOGUE. * doc/gccint/target-macros/tm.rst.in: 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. I'm not sure how we'll enforce the no target independent code motion limitation that this seems to need and the exception made for reorg is hackish in that it appears we just rely on the fact that reorg isn't run for the one target where this matters. That does make me wonder if we should future proof this ever so slightly -- is there a reasonably easy way to fail if a target were to define delay slots and the need for late prologue/epilogue? If so, that seems advisable. No objection to the meat of the patch, just wondering a bit about the additional sanity checking we can do... Jeff
[PATCH] Allow prologues and epilogues to be inserted later
Arm's SME adds a new processor mode called streaming mode. This mode enables some new (matrix-oriented) instructions and disables several existing groups of instructions, such as most Advanced SIMD vector instructions and a much smaller set of SVE instructions. It can also change the current vector length. There are instructions to switch in and out of streaming mode. However, their effect on the ISA and vector length can't be represented directly in RTL, so they need to be emitted late in the pass pipeline, close to md_reorg. It's sometimes the responsibility of the prologue and epilogue to switch modes, which means we need to emit the prologue and epilogue sequences late as well. (This loses shrink-wrapping and scheduling opportunities, but that's a price worth paying.) This patch therefore adds a target hook for forcing prologue and epilogue insertion to happen later in the pipeline. Tested on aarch64-linux-gnu (including with a follow-on patch) and x86_64-linux-gnu. OK to install? Richard gcc/ * target.def (use_late_prologue_epilogue): New hook. * doc/gccint/target-macros/miscellaneous-parameters.rst: Add TARGET_USE_LATE_PROLOGUE_EPILOGUE. * doc/gccint/target-macros/tm.rst.in: 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. --- .../miscellaneous-parameters.rst | 5 +++ gcc/doc/gccint/target-macros/tm.rst.in| 22 ++ gcc/function.cc | 43 +++ gcc/passes.def| 3 ++ gcc/target.def| 21 + gcc/tree-pass.h | 2 + 6 files changed, 96 insertions(+) diff --git a/gcc/doc/gccint/target-macros/miscellaneous-parameters.rst b/gcc/doc/gccint/target-macros/miscellaneous-parameters.rst index e4e348c2adc..b48f91d3fd2 100644 --- a/gcc/doc/gccint/target-macros/miscellaneous-parameters.rst +++ b/gcc/doc/gccint/target-macros/miscellaneous-parameters.rst @@ -551,6 +551,11 @@ Here are several miscellaneous parameters. of the if-block in the ``struct ce_if_block`` structure that is pointed to by :samp:`{ce_info}`. +.. include:: tm.rst.in + :start-after: [TARGET_USE_LATE_PROLOGUE_EPILOGUE] + :end-before: [TARGET_USE_LATE_PROLOGUE_EPILOGUE] + + .. include:: tm.rst.in :start-after: [TARGET_MACHINE_DEPENDENT_REORG] :end-before: [TARGET_MACHINE_DEPENDENT_REORG] diff --git a/gcc/doc/gccint/target-macros/tm.rst.in b/gcc/doc/gccint/target-macros/tm.rst.in index 44f3a3b..2e789f8723d 100644 --- a/gcc/doc/gccint/target-macros/tm.rst.in +++ b/gcc/doc/gccint/target-macros/tm.rst.in @@ -3702,6 +3702,28 @@ [TARGET_CC_MODES_COMPATIBLE] +[TARGET_USE_LATE_PROLOGUE_EPILOGUE] +.. function:: bool TARGET_USE_LATE_PROLOGUE_EPILOGUE () + + Return true if the current function's prologue and epilogue should + be emitted late in the pass pipeline, instead of at the usual point. + + Normally, the prologue and epilogue sequences are introduced soon after + register allocation is complete. The advantage of this approach is that + it allows the prologue and epilogue instructions to be optimized and + scheduled with other code in the function. However, some targets + require the prologue and epilogue to be the first and last sequences + executed by the function, with no variation allowed. This hook should + return true on such targets. + + The default implementation returns false, which is correct for most + targets. The hook should only return true if there is a specific + target limitation that cannot be described in RTL. For example, + the hook might return true if the prologue and epilogue need to switch + between instruction sets. + +[TARGET_USE_LATE_PROLOGUE_EPILOGUE] + [TARGET_MACHINE_DEPENDENT_REORG] .. function:: void TARGET_MACHINE_DEPENDENT_REORG (void) diff --git a/gcc/function.cc b/gcc/function.cc index b54a1d81a3b..3b1ab5d09e5 100644 --- a/gcc/function.cc +++ b/gcc/function.cc @@ -6641,6 +6641,11 @@ public: {} /* opt_pass methods: */ + bool gate (function *) final override +{ + return !targetm.use_late_prologue_epilogue (); +} + unsigned int execute (function *) final override { return rest_of_handle_thread_prologue_and_epilogue (); @@ -6648,6 +6653,38 @@ public: }; // class pass_thread_prologue_and_epilogue +const pass_data pass_data_late_thread_prologue_and_epilogue = +{ + RTL_PASS, /* type */ + "late_pro_and_epilogue", /* name */ + OPTGROUP_NONE, /* optinfo_flags */ + TV_THREAD_PROLOGUE_AND_EPILOGUE, /* tv_id */ + 0, /*