This is the mail archive of the 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] Fix dominator bug

On Wednesday 07 January 2004 17:18, Zdenek Dvorak wrote:
> Hello,
> > > > > Which reminds me, have you seen any compile-time
> > > > > regressions
> > > > > due to this change, Steven?
> > > >
> > > > Only dead code removal is transformation I can think of that would
> > > > work with this code without any other dominance tree manipulation.
> > > > But dead basic blocks can't be in the dminator tree anyway (we abort
> > > > while building the datastructure)
> > >
> > > We do not (we have no way of knowing about them, once we throw the
> > > basic block away).
> >
> > I meant that we abort when we attempt to build dominator tree for CFG
> > with unreachable basic blocks.
> > I would agree that something should happen when basic block is removed
> > and it is still in the dominator tree, just I would preffer it to be
> > abort instead of silent removal of the block from the tree, since any
> > transformation that makes blocks unreachable has to either invalidate
> > the dominance or update it in more complex way by hand, so the abort
> > would be reminder to do it instead of keeping tree silently
> > inconsistent.
> There is a verify_dominators call in tree_verify_flow_info, which would
> inform you about this.  The basic block needs to be removed from the
> dominance tree in any case, and doing it separately whenever you remove a
> block seems clumsy.

Zdenek, are you going to craft a patch for this problem?  This potentially
breaks the dominator optimizer as well; we have this code in tree-ssa-dom.c:

      /* We may have made some basic blocks unreachable, remove them.  */
      cfg_altered |= remove_unreachable_blocks ();

      /* If the CFG was altered, then recompute the dominator tree.  This
         is not strictly needed if we only removed unreachable blocks, but
         may produce better results.  If we threaded jumps, then rebuilding
         the dominator tree is strictly necessary.  */
      if (cfg_altered)
          cleanup_tree_cfg ();
          calculate_dominance_info (CDI_DOMINATORS);

But the "calculate_dominance_info (CDI_DOMINATORS);" call immediately
returns because it thinks that the dominance info is up-to-date.


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