[PATCH] Do framep replacement even on RHS outside of MEM contexts (PR debug/44694)

[Jakub Jelinek]

On Tue, Jun 29, 2010 at 04:33:26PM +0200, Richard Guenther wrote:
> On Tue, 29 Jun 2010, Jakub Jelinek wrote:
> > On the ginac.ii testcase cc1plus spends huge amount of time in var-tracking.
> > The problem is that there are many variables with values sp + const_int
> > (e.g. this pointers for huge amount of methods) and code to handle
> > reversible ops results in very long loc_chain lists (up to 3740 entries),
> > where the sp value is equvalenced with (plus (some_other_value) (const_int N))
> > for many different values (and corresponding offsets).
> > 
> > Fixed by canonicalizing sp (resp. hardfp) to (framep) + offset
> > even outside of MEM addresses when on the RHS and not doing
> > reversible ops for framep - which doesn't buy us anything, framep is always
> > computable using DW_OP_fbreg anywhere in the function.
> > 
> > The speedup for ginac.ii -g -O2 is from over 3 minutes to 16 seconds.
> > 
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> Ok.  Does this also apply to the branch?

I guess so, I'd just wait for a few days before backporting it.

	Jakub