------- 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) [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. (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. 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 "/* 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? 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. 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. */ 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)". o The comment explaining what 'resolve_dep' does can be inlined together with its code. +/* 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; +} +/* Attach NEXT to the next field pointed to by PREV_NEXTP. */ ^^^^^^^^^^^N to appear after node X whose &DEP_NODE_NEXT (X) is given by PREV_NEXT_P +static void +dep_node_attach (dep_node_t n, dep_node_t *prev_nextp) better place +dep_node_check_p (dep_node_t n) next to +dep_nodes_check_p (dep_node_t n) +/* Make a copy of FROM in TO with substitutin consumer with CON. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^substituting consumer with CON. Ayal. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071