On Jan 4, 2012, Jakub Jelinek <ja...@redhat.com> wrote: > Before the htab expansion > cselib_lookup on r1 - 1 gave value 18:18 which contains the right value, but > doesn't have the hash value for r1 - 1 (8169), thus is found only by > accident. Unfortunately after the expansion we don't look at the 18:18 > value at all, don't find a value and thus a new value for r1 - 1 is > created (27:8169). Unfortunately the expected MEM value is in 18:18's > addr_list, not in 27:8169, so add_stores doesn't find it (and is create=0 > call, thus it returns NULL).
The problem was a bug in the hash number computation for the reverse operation, that used the hash number of the original r1's VALUE when it was in a register, but didn't use it when we computed the hash code of the expression with a VALUE instead of the REG. This patch fixes expression hash computation so that it uses the hash code of a VALUE just as it would for REGs and MEMs, so that we compute the same hashcode and locate the VALUEs for reverse expressions correctly. Regstrapped on x86_64-linux-gnu and i686-linux-gnu, verified to solve the ARM problem, with and without your patch. I'm checking it in as obvious.
Index: gcc/cselib.c =================================================================== --- gcc/cselib.c.orig 2012-01-06 14:18:38.954548069 -0200 +++ gcc/cselib.c 2012-01-06 14:18:44.952460886 -0200 @@ -1035,6 +1035,10 @@ cselib_hash_rtx (rtx x, int create, enum switch (code) { + case VALUE: + e = CSELIB_VAL_PTR (x); + return e->hash; + case MEM: case REG: e = cselib_lookup (x, GET_MODE (x), create, memmode);
-- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer