Hashing algorithm for cselib causes bootstrap differences

[Bernd Schmidt]

On Thu, 23 Nov 2000, Richard Earnshaw wrote:
> 
> Note that insn 143 sets r8 as an SImode register, while insn 89 sets it as 
> a QImode register.  Now the hashing algorithm used for this will often 
> produce hash values that differ by exactly 2, since the only difference in 
> the hash calculations is the integer replacement for the mode that is 
> included.
> 
> Now, the key to the problem is when a hash table conflict occurs while 
> trying to look up equivalents for insn 89.  When one does, we increment 
> the hash bucket number by hash2, but in this case, hash2 is 2, so we hit 
> the bucket for the previous set.  Since constants have no mode, 
> rtx_equal_for_cselib_p declares the two entries to be equivalent.

I'm with you so far...

> Why does this cause a bootstrap comparison failure?  Well, the hashing 
> algorithm for a symbol_ref is to use the pointer to the symbol.  But the 
> address for this differs between the stage1 compiler and the stage2 
> compiler.  It just so happens that during stage2 the hash bucket assigned 
> is exactly the same as for the const 0 in insn 89.

However, I don't see yet why this is bad.

> I think it is a really bad idea that we use a pointer for the hash entry 
> of a symbol_ref, since it means that only small changes elsewhere in the 
> compiler (for example, even turning on or off some other independent 
> feature) can change the output in an unexpected way.

Why would the hash value have an influence on the code we generate?

> There is also the issue of whether rtx_equal_for_cselib_p should have 
> allowed these two chains to match.  Since we include the mode when hashing 
> a constant: surely we should include the mode when comparing them for a 
> match?

Yes, this does sound like a bug.  I think this is more likely to be the
cause of your comparison failure.  I'll look into it.


Bernd