On 03/28/2011 10:32 AM, Jakub Jelinek wrote: > Say vt_add_function_parameter is called for first parameter in %rdi, > cselib_lookup_from_insn gives us VALUE 2:2 for it. We add > (entry_value:DI (reg:DI %rdi)) to list of locations for that VALUE. > The second cselib_lookup_from_insn gives us VALUE 3:217, which will > have locations (value:DI 2:2) (the one we've injected there) and > (entry_value:DI (reg:DI %rdi)). Then when (entry_value:DI (reg:DI %rdi)) > appears in some DEBUG_INSNs, it will give (value:DI 3:217) > and vt_expand_loc_callback will use the first location for it > (i.e. (value:DI 2:2) ) and either it will see the value is still live > in %rdi, some other register or memory, or, if nowhere else, in > (entry_value:DI (reg:DI %rdi)). The 3 cselib.c changes from this > patch ensure that the hash value for (entry_value:DI (reg:DI %rdi)) > will always be the same and (value:DI 3:217) will never be flushed from > the hash table, even when e.g. on next bb's boundary we flush > all registers from the hash table, or e.g. when movl $123, %edi > is seen in the insns.
Ok, thanks for the explanation. All the changes make sense now. > I will look into creating helper inlines to reduce code duplication. Please. You can do this as a follow-up if you prefer. >>> (cselib_hash_rtx) <case ENTRY_VALUE>: If ENTRY_VALUE_EXP >>> is a REG_P or MEM_P with REG_P address, compute hash directly >>> instead of calling cselib_hash_rtx on ENTRY_VALUE_EXP. >> >> Why? > > Because REG and MEM hash based on their current value in cselib: > case MEM: > case REG: > e = cselib_lookup (x, GET_MODE (x), create, memmode); > if (! e) > return 0; > > return e->hash; > In ENTRY_VALUEs which are function invariant I want it to hash always > the same. Ok, with something akin to this as a comment. r~
