------- Comment #10 from rguenther at suse dot de 2010-01-08 11:09 ------- Subject: Re: Random code-generation differences with GRAPHITE
On Thu, 7 Jan 2010, sebpop at gmail dot com wrote: > > > ------- Comment #6 from sebpop at gmail dot com 2010-01-07 17:58 ------- > Subject: Re: Random code-generation differences > with GRAPHITE > > After your change, there remains three users of htab_hash_pointer in graphite: > > In if_region_set_false_region, there is a use of htab_hash_pointer, > but that matches the use of the loops->exits htab as also used in > get_exit_descriptions. > > The next two, are: > > hashval_t > ivtype_map_elt_info (const void *elt) > { > return htab_hash_pointer (((const struct ivtype_map_elt_s *) > elt)->cloog_iv); > } > > static inline hashval_t > clast_name_index_elt_info (const void *elt) > { > return htab_hash_pointer (((const struct clast_name_index *) elt)->name); > } > > and they are a bit more difficult to change, as it is the interface > with CLooG that uses a "char *" to identify loop induction variables. > In both cases, we're hashing on that string identifier. > > Should these two functions be changed as well? If you ever end up traversing those hash tables then yes, I suggest to use htab_hash_string instead. If you are not traversing them you might want to consider using the somewhat more efficient pointer_map structure (but that's only an optimization then). Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42641