Re: 0001-Don-t-skip-prologue-instructions-as-it-could-affect-.patch

[Segher Boessenkool <segher@kernel.crashing.org>]

On Fri, Jul 23, 2021 at 10:27:37AM -0600, Jeff Law wrote:
> 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.

Yeah.  Unfortunately it isn't trivial to see if this is a premature
optimisation, or if this is needed for correctness instead.  But it is
stage 1 still :-)

> >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.

Yup, if the *logues are just RTL, that RTL follows just the normal
semantics of RTL.  This means that dead code can be deleted, etc.  Well
that is about the most interesting transform that can be done so late
in the compilation pipeline :-)


Segher