Hashing algorithm for cselib causes bootstrap differences

[Richard Earnshaw]

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

Mainly because I like to see consistency when I'm trying to debug a 
problem.  In this case, the (internal) behaviour of the program when built 
with optimization on differs from that when optimization is off: items go 
into different hash buckets.  This makes tracking down problems 
exceedingly hard.

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

It shouldn't if it weren't for the problem below; but as it stands it does.

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

Great.  I'm afraid I can't generated you a test case, since it only fails 
on a arm-NetBSD machine and then only when using the built-in preprocessor 
(using preprocessed output the problem goes away -- another subtle change 
that alters the internal behaviour of this pass).  I guess any set of 
system headers other than mine would alter the behaviour as well.

Richard.