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]

Re: Patch: cse "library" routines


>>>>> "Bernd" == Bernd Schmidt <bernds@balti.cygnus.co.uk> writes:

    >> > + /* A table that enables us to look up elts by their value.
    >> */ > + #define NBUCKETS 32 > + #define VALUE_HASH(V) ((V) %
    >> NBUCKETS) > + > + static cselib_val *table[NBUCKETS];
    >> 
    >> Why your own hash table implementation rather than one of the
    >> couple of dictionary-type widgets we already have in libiberty?

    Bernd> I think the main reason is that I duplicated some parts
    Bernd> from cse.c.  I've had a brief look at hashtab.c now.  I
    Bernd> could probably use it but some parts might get more
    Bernd> complicated; e.g. the code needs to compute the hash value
    Bernd> before inserting a new element into the table (to avoid
    Bernd> entering particular expressions which can't be hashed), so
    Bernd> we'd compute the hash value twice.  IMO not using hashtab.c
    Bernd> avoids some complications, but I won't object if you want
    Bernd> this changed.

My two cents: using the stuff in libiberty is a big win in the long
run.  I'd suggest adding an interface to the hash table to allow
passing in the hash code, rather than having the hash table machinery
compute it.  That solves the performance problem.  To the extent that
we can a) increase the power of libiberty and b) reduce the number of
special-purpose data structures in GCC we win.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

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