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] Cleanup and enhance dominator infrastructure


In message <1071785157.7490.11.camel@frodo.toronto.redhat.com>, Diego Novillo w
rites:
 >On Thu, 2003-12-18 at 09:37, Zdenek Dvorak wrote:
 >> 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.


 >> ! 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.

jeff








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