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] Fix dominator bug


> Hello,
> 
> > > On Wed, 2004-01-07 at 10:15, Jan Hubicka wrote:
> > >
> > > > Perhaps we can just add an sanity check here and insist on caller to
> > > > do
> > > > whathever is needed to update dominance.
> > > >
> > > But in this particular case, it's easy to keep the dominance info
> > > up-to-date.  The call to delete_from_dominance_info shouldn't be
> > > expensive.
> 
> calling it is definitely a good idea, since it prevents a memory leak
> and it is also neccessary to keep the tree consistent.  The only reason
> we do not see any problems with the block not being removed is because
> anything that makes the edges to be removed (and thus may create
> unreachable code) invalidates the dominance information (making it only
> conservatively correct) and the whole tree is then recomputed from
> scratch before using it.
> 
> > > 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.

However since we do check this in verify_flow_info later anyway, I don't
think this is critical, so I would be happy with the silent removal too.
(do we notice such a forgotten blocks in verify_flow_info?)

Honza
> 
> Zdenek


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