[tuples] the intermittent bootstrap problem.

[Diego Novillo]

On 04/24/08 13:05, Rafael Espindola wrote:
>>  That is intermittent indeed.  I suppose you also tried running cc1 directly
>> from the command line.
> 
> I did.
>>  Yes, this would make it almost impossible to find a reduced testcase, but I
>> don't see how this would be affected by running on makefile vs. commandline,
>> unless you're hashing addresses (and even then...).  Or you can patch
>> hashtab.c to force slot 0 independent of the hash.  That would be slow
>> though. :-)
> 
> I might try something like that (or reducing the hash size at least).
> 
> One interesting problem I don't understand. Lets say we have a stmt "a
> = b + c". We add it to the table and look for it *before* it is
> modified. lookup_avail_expr will find it (as expected) and return its
> LHS. Shouldn't we end up replacing "a = b + c" with the uninitialized
> "a"? What prevents us from doing it? On trunk we don't call
> lookup_avail_expr with the same stmt twice?

That's not the way the original DOM code worked.  It relies on the 
modified statement to never collide again.  In fact, it relies on 
collisions to always have the exact same hashing value, which is a bit 
strict but I think Jeff was looking for perfect hashing at the time.

Bill needed to change this hashing scheme, so now this test for perfect 
hashing may not be valid anymore.  The problem here is that we are 
getting two different hash values for the same statement.  Which is 
understandable given that we changed the operands on it.  However, the 
hashing function is returning the same slot for the two hash values.

This tells me that the hashing scheme we are using is relying quite a 
bit on pointer hashing, which is entirely possible.  On mainline, when 
we do replacements, we copy the values into a new tree, so the hashing 
value we get after that is very different.

For now, I would probably go with the option of clearing out a statement 
out of AVAIL_EXPRs if we do a replacement on it.


Diego.