Re: Patch: cse "library" routines

[Richard Henderson <rth at cygnus dot com>]

On Tue, Mar 14, 2000 at 11:33:32AM +0000, Bernd Schmidt wrote:
> > I'm not quite sure I understand this.  Why would you not
> > want to compare two things of the same type?  It seems like
> > a very good way to get confused.
> > 
> > > ... and the two _with_hash variants of
> > > htab_find and htab_find_slot (to avoid calling hashfn on the second argument
> > > of the equality test which no longer needs to be an entry).
> > 
> > And since you've now got the hash value stored in the cselib_val,
> > why do you need the _with_hash variants?  You've all but eliminated
> > the cost of "computing" the value.
> 
> Before creating a new cselib_val, I need to find whether there's already one
> that is equal to a given rtx (i.e. it has a location for which
> rtx_equal_for_cselib_p returns 1 if compared to the given rtx).  This is a
> comparison of cselib_val against rtx. 

> I'd have to make up a dummy cselib_val to store the rtx into to avoid that;
> in that case I could also store the hash value in the dummy, but I thought
> that kind of thing was too ugly.

It doesn't seem that awkward to me.  Less so than the weird usage
of the hash table.

Which brings to mind another question, actually.  You're hashing
rtxs, and comparing rtxs, but storing cselib_vals in the hash table.

But one cselib_val is associated with more than one rtx.  Given
that two rtxs will hash differently, how does one actually find
the cselib_val associated with the second rtx? 

If the cselib_val is in the hash table only once, then I don't see
how the second rtx can be wired up at all.  If the cselib_val is
in the hash table more than once, then using cselib_val->value as
the hash must be wrong.

Surely I miss something?


r~