Re: Rewrite of PROPOSAL 001213.1 re default location

[Jim Dehnert <dehnert at transmeta dot com>]

In reply to Jason's query and Ron's later request for a straw poll:

Jason Merrill wrote:
> Setting that aside, it seems that we have three ideas of what it means to
> have overlapping entries in a location list, which the 2.0 spec says
> "describe a situation in which an object exists simultaneously in more than
> one place".
> 
> 1) The entries represent the live locations of different instances of
>    the variable.  (Ron)
> 2) The entries represent multiple live locations for the same instance of
>    the variable.  (Jim)
> 3) The entries represent multiple locations for the same instance of the
>    variable, only the innermost of which is live.  (Michael)
> 
> I agree with Jim that the current wording is too vague.  What do you think
> it ought to mean?  My inclination is toward #3.

My preference would be for #3 as well (#2, attributed to me, is just
my reading of the current wording).  My reasoning is as follows:

- First, I would restate it as:

  The entries represent multiple locations for the same instance of the
  variable, only the first of which is live.  (Last is OK, too, but first
  would make finding the value a bit faster for the debugger.)

1 I assume that the objective is to make the current location lists serve
  the purpose originally raised by Ron, namely supplying a compact default
  location for variables that move around a lot.  If that's not the case
  (e.g. if a separate default mechanism is defined), then I think things
  are much less clear.

2 Many compilers today (certainly SGI's) can and do allocate data items
  to "home" memory locations by default, but often move them to registers
  for extended ranges that may include both references and updates.  The
  latter (updates) will make the home location out-of-date (invalid).
  Therefore, if we are going to treat it as serving the purpose of Ron's
  default, with a maximal range in the loclist, it is important that the
  debugger know enough to look for the current value in the currently live
  register rather than in the home location.  That is the reason I prefer
  to define this by clarifying that one of the ranges (first or last) takes
  precedence for references.

3 At the same time, it also occurs that multiple locations may be live.
  The example I provided a while ago was on procedure entry.  A parameter
  passed in a register is copied shortly after entry to its home location
  on the stack, and will be used from there later (i.e. it's live), but
  the original copy in the parameter register will be use again before it
  is discarded, so it's live too.  Therefore, the debugger can get the
  value from either (consistent with the preference in (2), but it must
  update both.

As for the other interpretations:

- #2 (multiple locations of a single instance, all equal) can't provide
  an all-inclusive default range AND deal with temporary register allocation
  as I described in (2) above -- unless one of the locations is
  distinguished, the debugger may report the dead version's value.

- Although #1 (multiple instances of a variable) certainly represents a
  situation that occurs in optimized code, especially in software
  pipelining, I think it's much less common than the situations I described,
  and I don't think a debugger will be able to deal with it based just on
  modifying the loclist definition anyway.  So I'd be inclined to force
  someone who wants to deal with it to define other mechanisms.

Jim