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 bootstrap failure caused by tree-ssa-loop.c


> In message <1070903665.17667.28.camel@p4>, Andrew MacLeod writes:
>  >On Sun, 2003-12-07 at 11:57, Diego Novillo wrote:
>  >> On Sun, 2003-12-07 at 11:52, Jan Hubicka wrote:
>  >> 
>  >> > This looks strange.  Why dumping code should be tied with checking?  I
>  >> > definitly would like to see dumps out of checking disabled compiler.
>  >> > 
>  >> See the code.
>  >> 
>  >> Zdenek just provided an empty tree_ssa_loop_opt() which merely dumps the
>  >> function with checking enabled.
>  >> 
>  >Actually, the flag for the loop optimizations should probably be off by
>  >default. Our normal operating method is to have new passes turned off by
>  >default until they are in a reasonable state where they demonstrate
>  >something of signdficance, and all the bugs are worked out. Its lets the
>  >author of the pass fiddle around a lot more without impacting other
>  >people.
> Correct.  And for this code I already know it's got some problems.  Or more
> correctly it interacts badly with the rest of the SSA path.
> 
> The dominator tree right now is fundamentally tied to block indices.  If we
> add or remove blocks, then we effectively invalidate the dominator tree
> (that's probably not a wise thing, but it's the way things are right now).
> 
> Anyway, the loop code creates new basic blocks, then re-computes block
> indices.  This totally horks the dominator tree -- and does so in a way
> that our code to detect the dominator tree being invalid does not detect.

So you mean that we keep the dominator bitmaps inside BB annotations and
believe them later in compilation?
That breaks not only by Zdenek's code.  Any edge splitting or such would
break it.  How it is supposed to work?

There is trivial way to verify dominators - just compute them again and
compare, I can add it into tree_verify_flow_info in the case we are
supposed to keep it incrementally safe, but I would say that recomputing
this thing at demand is the right way.

Honza
> 
> Then later we come along and run the dominator optimizer using this horked
> dominator tree -- which results in a variety of incorrect transformations
> which are caught by verify_ssa.
> 
> You can see this lossage in action if you have the loop code enabled and
> do a checking bootstrap with -O1.
> 
> jeff


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