[PATCH] ENTRY_VALUE fixes (PR debug/48203)

[Richard Henderson]

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~