[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