[Bug tree-optimization/42641] Random code-generation differences with GRAPHITE

[rguenther at suse dot de]

------- 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