------- Comment #58 from zaks at il dot ibm dot com 2007-01-15 15:30 -------
(In reply to comment #57)
> 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)
Enjoy! One suggestion that may help explain the data-structure, is to provide a
drawing of ddn with its dep and nodes connected.
> > 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.
Ah, on second thought, perhaps the important property of this struct is the
fact that it's a link on a forward or backward chain; so how about dep_link?
> > 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.
Ah, 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.
> 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.
You're right. There's probably not much to gain if anything paying an extra
pointer to save the fields of the conjugate dep_node. Perhaps only place
dep_def between back and forw (been too much into struct-reorg, I guess :). It
does seem wasteful to hold two 'data' pointers for such nearby offsets ... ;)
And another note: INSN_DEPS may be renamed INSN_BACK_DEPS to better distinguish
it from INSN_DEPEND (which in turn might be called INSN_FORW_DEPS). And maybe
INSN_RESOLVED_BACK_DEPS for consistency.
Ayal.
--
zaks at il dot ibm dot com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |zaks at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28071
