This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug rtl-optimization/78812] [5/6/7 Regression] Wrong code generation due to hoisting memory load across function call


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78812

--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 16 Dec 2016, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78812
> 
> --- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> (In reply to rguenther@suse.de from comment #6)
> > On Fri, 16 Dec 2016, jakub at gcc dot gnu.org wrote:
> > 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78812
> > > 
> > > --- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> > > (In reply to Richard Biener from comment #4)
> > > > Can't we insert on the edge and commit edge insertions late?  Or simply
> > > > split the block for this case?
> > > 
> > > Well, for the case of calls there typically are 2 edges, not just one (the
> > > abnormal one and normal fallthru), except for noreturn throwing calls.
> > > So inserting on the edges would usually mean undoing the hoisting.
> > > Note if the expression doesn't contain MEM (and isn't clobbered by the call,
> > > but that should just affect hard registers), hoisting it before the call is
> > > just fine.
> > 
> > But then sth is wrong with the dataflow problem ... maybe it somehow
> > assumes that a signle outgoing edge is always fallthru (and not EH)?
> > That is, inserting on EH edges is "tricky" at best...
> 
> Dunno, haven't looked into it in detail.  The hoisting has been from 2 spots,
> one after the call's fallthrough and another from the EH landing pad of the
> call (which is why emitting the expression after the call's fallthrough and
> duplicating after the EH landing pad would effectively undo the optimization).

Ok, but we obviously can't hoist to this place so presumambly have to
reflect that in the dataflow somehow (or prune its solution).  We have

          if (!pre_p && MEM_P (expr->expr))
            /* Note memory references that can be clobbered by a call.
               We do not split abnormal edges in hoisting, so would
               a memory reference get hoisted along an abnormal edge,
               it would be placed /before/ the call.  Therefore, only
               constant memory references can be hoisted along abnormal
               edges.  */
            {

but exactly the same reasoning applies to EH edges.  Thus

Index: gcse.c
===================================================================
--- gcse.c      (revision 243738)
+++ gcse.c      (working copy)
@@ -1757,7 +1757,7 @@ prune_expressions (bool pre_p)
         and, hence, there's no need to conservatively prune expressions 
on
         "intermediate" set-and-jump instructions.  */
       FOR_EACH_EDGE (e, ei, bb->preds)
-       if ((e->flags & EDGE_ABNORMAL)
+       if ((e->flags & (EDGE_ABNORMAL|EDGE_EH))
            && (pre_p || CALL_P (BB_END (e->src))))
          {
            bitmap_and_compl (antloc[bb->index],

doing that if only pre_p is probably not necessary (but it'll be
only !CALL_P for non-call-exceptions).

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]