Patch: cse "library" routines
Tue Mar 14 06:07:00 GMT 2000
> 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?
There's never more than one location which is not a REG or a MEM. That
one determines the hash value (if there's no such location, the hash
value is useless, and chosen at random). REGs and MEMs aren't looked
up through the hash table at all (REGs go through the reg_values varray;
MEMs are looked up by their address). So if you have
(set (reg) (plus (...) (...))
we'll create a hash entry for the PLUS, and then add the reg to the
locations. If we later encounter a PLUS of the same form again, we
can find it in the hash table because it will get the same hash value.
More information about the Gcc-patches