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] Irreducible loops self checking

> In message <>, Jan Hubicka writes:
>  >Hi,
>  >this patch adds code to ensure that we don't introduce new irreducible
>  >region during optimization.  I don't want to use loop code for it as it
>  >unshares loop regions and checking code should not clobber the CFG so I
>  >used structural analysis code I wrote earlier.
>  >While this is quite violent sollution for such a small problem, I think
>  >the code will become more usefull in the future as it serves interesting
>  >alternative to the loop discovery code (in some way it is easier to keep
>  >up to date and it does not suffer quadratic behaviour) and it can be
>  >used to make pretty printer dumps output structured programs again.
>  >(Zdenek did some work on this independently so I want to check first his
>  >work before making some more work.)
>  >
>  >Regtested/bootstrapped i386 together with SSA patch. OK?
>  >
>  >Honza
>  >
>  >2003-11-21  Jan Hubicka  <>
>  >	* tree-optimize.c: Include sa.h.
>  >	(optimize-function_tree): Check amount of improper regions.
>  >	* sa.c: New file.
>  >	* sa.h: New file.
>  >	* (sa.o): New.
>  >	(tree-optimize.o): Depend on sa.h
> This seems like massive overkill just for the sake of detecting 
> irreducible regions and printing.    Before going with something this

Sure, I would not implement it for these two.  I just grabbed code I
used few years ago but never managed to push out the code.
(it didn't really worth it)

> large, I'd like to see some significant tangible benefit.
> And I would think that we'd either need to make this a first class entity
> to actually get any of those benefits.  ie, if we update the CFG, then we
> would need to be updating the CFG used to do structural analysis and
> update the results of structural analysis.
Updating structural tree in general is very dificult  (well equivalent
to update syntactic control flow structure we used to have) and I think
the DJ graphs produce better alternative for incremental data flow.
Only use for the syntactic tree I use now is for pretty printing or
possible some kind of optimizations that are beter to think about in
source-style, lets say branch probabilities...
> You might consider T1/T2 if you really want to verify that we don't
> introduce irreducible regions.   That ought to be a lot simpler.

I can simply compute dominators and DFS order and look for back edges
where destination does not dominate source.  That does have similar
running time to the syntactic analysis tought..

> jeff

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