[tree-ssa] Cleanup and enhance dominator infrastructure

Zdenek Dvorak rakdver@atrey.karlin.mff.cuni.cz
Tue Jan 6 10:31:00 GMT 2004


Hello,

>  >> > > as pointed out by Daniel, there is a mistake in the part of the patch i
>  >n
>  >> > > tree-ssa-pre.c (I did not notice that the arguments of
>  >> > > fast_a_dominates_b are reversed wrto dominated_by_p).
>  >> > 
>  >> > Could you send me a complete patch including these new fixes?
>  >> 
>  >> here is the actual version of the patch; nothing else was changed
>  >> (except for resolving a few conflicts), so the comments/changelogs at
>  >> the original message should be applicable.
>  >
>  >The new dom children interface is much nicer than before. Thanks.  A
>  >couple of comments below:
>  >
>  >In the definition of enum dom_state add a comment specifying that the
>  >enum values are ordered from "worst" to "best".  We use those semantics
>  >in places like cleanup_control_expr_graph.
>  >  
>  >> ! #ifdef DEBUG_ET
>  >>
>  >Have you bootstrapped with DEBUG_ET enabled?
> If it's as slow as Zdenek claims, then we might as well just kill DEBUG_ET.

the code was really useful to debug the thing.  I would like to keep it
there for the case it sometimes in the future turns out there is a bug
somewhere in the code.

>  >> ! static int len;
>  >> ! static void *datas[100000];
>  >> ! static int depths[100000];
>  >>
>  >Please #define these values and add guards in record_path_before_1.
> Err, really?  So we're just going to blindly allocate nearly a megabyte
> of static data on a 32bit machine?  That's lame, really lame.  We're better
> off getting that much data from the heap via malloc/free.

These arrays are there only when DEBUG_ET is enabled.

Zdenek



More information about the Gcc-patches mailing list