------- 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
