On 7/22/2021 7:04 AM, Richard Biener via Gcc-patches wrote:
On Thu, Jul 22, 2021 at 9:02 AM Bin.Cheng via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
Gentle ping. Any suggestions would be appreciated.
So just to say something - does the existing code mean that any use of
the alias info on prologue/epilogue insns is wrong? We have
/* The prologue/epilogue insns are not threaded onto the
insn chain until after reload has completed. Thus,
there is no sense wasting time checking if INSN is in
the prologue/epilogue until after reload has completed. */
bool could_be_prologue_epilogue = ((targetm.have_prologue ()
|| targetm.have_epilogue ())
&& reload_completed);
so when !could_be_prologue_epilogue then passes shouldn't run into
them if the comment is correct. But else even epilogue stmts could appear
anywhere (like scheduled around)? So why's skipping those OK?
These insns don't exist until after reload has completed. I think this
code is just trying to be more compile-time efficient and not look for
them when they're known to not exist.
As for why they're skipped? That seems wrong to me. That was added by
Kenner:
https://gcc.gnu.org/pipermail/gcc-patches/2000-May/031560.html
Interestingly enough myself (and others) preserved that behavior through
several updates to this code.
Are passes supposed to check whether they are dealing with pro/epilogue
insns and not touch them? CCing people that might know.
Generally most passes can treat them as any other RTL.
Jeff
