[Bug debug/43176] var-tracking fails to notice a value change

[jakub at gcc dot gnu dot org]

------- Comment #3 from jakub at gcc dot gnu dot org  2010-02-26 15:56 -------
The reason for the two different VALUEs for the same thing here (where we have
just one normal bb) is that vt_add_function_parameters does
cselib_lookup/cselib_preserve_value calls after processing the last bb, so of
course can't be the same VALUE as the one in the first bb (because the hash
table is flushed).  Maybe we could cure that by splitting parts of
vt_add_function_parameter into a helper, which would then be called before
going through the bb's and would populate an array with some compute info for
the parameters, then when processing first bb always before processing insns
would
do a cselib_lookup/cselib_preserve_value and again remember in the array, then
at the end of vt_initialize do the rest from the array.

Perhaps it isn't so important though, we can have different VALUEs for the same
thing anyway due to merging of stuff at the start of bb.

What we perhaps could do to help allocate slightly fewer VALUEs would be not to
process in vt_initialize just one bb at a time with cselib flushing immediately
after it, but process whole ebbs at a time.  Will try to play with that.

That said, aren't VALUEs that are equivalenced at some point equivalent for
their entire lifetime?  If so, it might be better to just share the
loc_chain/cur_loc for them using indirection or by having some variable
structures act as links to other variables.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43176