This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils 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: parallelized 'ld'?


> On Wed, Jun 09, 2004 at 07:52:16PM -0400, DJ Delorie wrote:
> > +       fprintf(stderr, "dj: expand count %d size %d to %d\n", table->count, table->size, newsize);
> 
> You'd better remove the debug output. :)

Yeah, well... ;-)

> > +       newtable = ((struct bfd_hash_entry **)
> > + 		  objalloc_alloc ((struct objalloc *) table->memory, alloc));
> > +       memset ((PTR) newtable, 0, alloc);
> 
> No need for (PTR).

That's consistent with the way the table is managed elsewhere.  It
should probably be cleaned up with the K&R->ANSI conversion.

> > + 	while (table->table[hi])
> > + 	  {
> > + 	    int index;
> > + 	    he = table->table[hi];
> > + 	    table->table[hi] = he->next;
> > + 	    index = he->hash % newsize;
> > + 	    he->next = newtable[index];
> > + 	    newtable[index] = he;
> > + 	  }
> 
> This will reverse entries with a duplicate key, won't it?  I don't think
> it matters at the moment, even though we have duplicates in the section
> hash table, but it might cause a problem at some stage.

Resizing the table screws up the order in general.  Plus, if anyone is
relying on the order of items in a HASH TABLE, then IMHO they deserve
to get broken.  Besides, at some point in the future perhaps we could
replace each bucket's linear chain with a binary tree or something
more efficient.  I'd rather discover any such dependencies earlier
than later.


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