This is the mail archive of the gcc-patches@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]

Re: [tree-ssa] DCE with control dependence again (with numbers, for a change)


In message <200401202116.37604.s.bosscher@student.tudelft.nl>, Steven Bosscher 
writes:
 >On Tuesday 20 January 2004 20:22, law@redhat.com wrote:
 >> As I mentioned, a few minor nits in the code:
 >>
 >>
 >>
 >>
 >>
 >> #include "bitmap.h"
 >>
 >> bitmap.h is already included by tree-flow.h a few lines later.
 >
 >Hmm I didn't want to rely on that.  IMO every file should pull in its
 >own dependencies, or suddenly your code will fail to compile when you
 >try something smart in one of the include files (like testing ebitmaps
 >for tree-flow).
Generally true, except we do have certain things you can rely upon
for GCC because we have hard dependencies in the header files themselves.

You can get a list of the hard dependencies within the header files by
looking at Makefile.in for variables of the form:

FOO_H = <list of header files >

As I said, I wouldn't consider this a major issue.  If you'd really prefer
to have it explicitly included, then I won't object any further.

 >> It appears that you mark all GOTO_EXPRs as being inherently necessary -- I
 >> would think that the only ones you need to mark as inherently necessary
 >> would be those which create abnormal edges.  ie, you don't want a block to
 >> be marked as necessary just because it ends with a goto statement.  Right?
 >> Or am I missing something?  [ I see the old code also had that behavior. 
 >> Odd. ]
 >
 >Hmmm, in my first post (somewhere in the archives) I did not mark simple
 >gotos inherently necessary...  Later I decided that they were, though
 >the original patch did work.  I suppose was misguided by all the
 >discussions about the CFG and control statements, but I think the first
 >choice was right after all.  I'll fix this up.
I think you can just remove the case statement for GOTO_EXPR.

The goto will still get marked later in the same routine via:


  /* If the statement has volatile operands, it needs to be preserved.  Same
     for statements that can alter control flow in unpredictable ways.  */
  if (ann->has_volatile_ops
      || is_ctrl_altering_stmt (stmt))
    {
      mark_stmt_necessary (stmt, true);
      return;
    }


I'd leave the latter hunk in for now -- while I think it could ultimately
be removed, I believe doing so will require adjustments elsewhere -- and
I don't really want to hold up the improved tree-ssa-dom.c on this trivial
issue.


 >>   /* If we have determined that a conditional branch statement contributes
 >>      nothing to the program, then we not only remove it, but change the
 >>      flowgraph so that the block points directly to the immediate
 >>      post-dominator.  The flow graph will remove the blocks we are
 >>      circumventing, and this block will then simply fall-thru to the
 >>      post-dominator.  This prevents us from having to add any branch
 >>      instuctions to replace the conditional statement.  */
 >>
 >> "The flow graph will remove ..." -> "The blocks we are circumventing will
 >> be removed by cleanup_cfg as they will have become unreachable." or
 >> something like that.  Think of "the flow graph" as a passive noun -- it's a
 >> datastructure.
 >
 >Ah yes, the comment is a literal copy of the old RTL ssa-dce code.
Then it's even possible that's my thinko.  I certainly recognized some
of the other comments in the updated tree-ssa-dce.c




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