Re: [tree-ssa] copy prop vs. debugging

[Andrew MacLeod <amacleod at redhat dot com>]

On Thu, 2003-07-03 at 12:48, law@redhat.com wrote:
> In message <wvlof0bvdws.fsf@prospero.boston.redhat.com>, Jason Merrill writes:
>  >When a temporary is copied into a variable, any dominated uses of that
>  >variable are replaced with uses of the temporary.  If all uses are
>  >dominated by such a copy, the variable is removed.  This obviously hurts
>  >debugging.
>  >
>  >This isn't a major problem in the current tree, but a patch I'm working
>  >on to always evaluate non-trivial expressions into temps causes it to
>  >happen much more frequently; now pretty much any modification of a user
>  >variable is a copy.
> Yes.  I've been pondering this as well -- I first noticed this effect
> when forcing the LHS of a MODIFY_EXPR to be a temporary if the RHS could
> throw.
> 
>  >I can think of two ways to address this:
>  >
>  >1) When coalescing, try to replace temps with user variables which are
>  >   copied from them.  This is an incomplete solution, but might be simpler
>  >   than:
> In the cases I was looking at, this was going to be reasonably effective.
> It's simply a matter of adding this support to the coalescer.
> 

I can do that when I add the stack-space reduction pass to the
SSA->normal coalescer. Ie, when I try to merge various non-conflicting
temporaries of the same type into a single variable. You certainly want
to prioritize it to merge any which have a copy first (so we can
eliminate the copy), and it should be simple enough to choose a user var
over a compiler temporary to represent the merged location in those
cases.

Does that also mean I shouldn't merge temporaries with user variables if
there is not a copy?  Debuugging might seem wrong if a user variable
isn't actually used in the last half of the program, but the value
changes all the time because we are reusing the stack slot... Or is that
OK?  It would complicate things a little bit to make sure that doesnt
happen.

Andrew