------- Comment #57 from mkuvyrkov at ispras dot ru 2007-01-15 07:52 ------- Subject: Re: [4.1 regression] A file that can not be compiled in reasonable time/space
Thanks! Very useful comments. I'm continuing to work on cleaning the patch (especially on writing the comments) and making code more transparent. Below are my comments on yours: zaks at il dot ibm dot com wrote: > ------- Comment #56 from zaks at il dot ibm dot com 2007-01-15 07:19 ------- > (In reply to comment #55) >> Created an attachment (id=12879) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12879&action=view) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12879&action=view) [edit] >> Patch for scheduler dependency lists. > > Looks like a pretty good cleanup IMHO. Here are some comments. > > o dep_def: representing a dependence edge including both producer and consumer > is very handy, albeit somewhat redundant as we're usually traversing all cons > connected to a pro or vice versa. This allows us to keep all things in one place - one of the things current deps don't provide. I.e., when changing some property of the dep we need to find a corresponding to that dep nodes in both backward and forward lists and apply the change to two places instead of one. (I.e., has its pros and cons, but mostly pros > I agree - also done in ddg.h/ddg_edge.) Maybe comment why both 'kind' and 'ds' > are needed, as one supersedes the other. There will be. Thanks. > > o dep_node_def: this is a node in a (doubly-linked) chain, but it represents > an > *edge* in terms of the data-dependence graph. The prev_nextp field is a "/* Right! I struggled to figure out the correct name and didn't prevail. Thanks for the tip. It'll be dep_edge. > Pointer to the next field of the previous node in the list. */" except for > the > first node on the list, whose prev_nextp points to itself, right? No. Prev_nextp field of the first node points to deps_list->first. This allows us not to distinguish first node from the others. I'll fix the comment. > > o dep_data_node_def: holding the two conjugate dependence edges together is > very useful when switching directions. But perhaps most of the accesses go in > one direction (e.g. iterating over cons of a pro), and having both conjugates > structed together may reduce cache efficiency. So you may consider connecting > each dep_node_def to its conjugate, not necessarily forcing them to be placed > adjacent in memory. Dep_def and both edges were placed in one structure so that they could be allocated and freed within a single alloc/free. As I understand you propose putting two pointers inside dep_edge_def: one to the dep_def and one to the opposite edge. Currently we have one pointer in dep_edge_def to the dep_data_node which have all that pointers. And probably I'm missing something, but I don't see how your way can improve cache efficiency. > > o To add to the checking routines, the following can be checked: every > dep_node_def is pointed-to by either its data->back xor its data->forw, right? > If so, this can be used to identify if a dep_node_def is forward or backward; > that all nodes on a list are forward (and share the same pro) or backward (and > share the same con); and to assert the following regarding L: > +/* Add a dependency described by DEP to the list L. > + L should be either INSN_DEPS1 or RESOLVED_DEPS1. */ Good idea. > > o insn_cost (insn, dep): maybe it's better to break this into insn_cost (insn) > of a producer regardless of consumers, and "dep_cost (dep)". Agree. > > o The comment explaining what 'resolve_dep' does can be inlined together with > its code. Agree. > > +/* Detach dep_node N from the list. */ > +static void > +dep_node_detach (dep_node_t n) > +{ > + dep_node_t *prev_nextp = DEP_NODE_PREV_NEXTP (n); > + dep_node_t next = DEP_NODE_NEXT (n); > + > + *prev_nextp = next; > + > + if (next != NULL) > + DEP_NODE_PREV_NEXTP (next) = prev_nextp; > maybe complete the detachment by adding: > DEP_NODE_PREV_NEXTP (n) = NULL; > DEP_NODE_NEXT (n) = NULL; Probably, you are right. > Ayal. Thanks, Maxim -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
