Re: fix for PR49888 var-tracking compile-time regression

[Jakub Jelinek <jakub@redhat.com>]

On Wed, Jan 16, 2013 at 08:28:59AM -0200, Alexandre Oliva wrote:
> PR49888 introduced clobber_overlapping_mems to detach VALUEs (and
> variables bound to them) from MEMs as the MEMs are modified.  This
> turned out to be quite expensive, particularly the computation of
> canonical addresses passed to alias dependency.
> 
> This patch introduces caching of the canonical addresses to alleviate
> this expensive operation.  We cache mappings that apply to the entire
> function, from equivalences recorded in the global cselib table, and
> mappings that apply only to the local basic block.  This cut down 2% of
> a full regstrap cycle, and about 1% of the time it took to build target
> libraries for C, C++ and Java.

Can you safely cache the canon addresses already during vt_initialize
(when cselib_* is still processing new insns, cselib VALUEs contain
REGs and MEMs that are flushed at the end of processing the current bb
in vt_initialize)?  In my earlier attempts to cache something in
var-tracking, I've always started caching at the end of vt_initialize,
when the VALUEs should be (with one small exception of
variable_post_merge_new_vals created VALUEs) pretty much stable, everything
should be flushed that needs to be flushed, etc.

Also, what effects (if any) does the patch have on the
.debug_info/.debug_loc size and coverage?

	Jakub