Re: Rewrite of PROPOSAL 001213.1 re default location

[David B Anderson <davea at quasar dot engr dot sgi dot com>]

Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Status: R

M. Eager writes:
|David B Anderson wrote:
|> 
|[ ] 
|> Consider the following trivial example.
|> 
|> int v = z                               point A, a springs into life.
|> 
|>         v moves to a register     point B.
|>                 v = y[k];            point C.
|> 
|> 
|>         v copied back to original loc  point D.
|> 
|> End of life of v, point E.
|> 
|> It's perfectly possible to describe this adequately with
|> dwarf location lists (in this case it takes 3 loclist entries,
|> but is most clearly shown as 4 lines).
|>   A to C, current in original location (only).
|>   B to C, current in register (ie, in both locations from B to C)
|>   C to D, current in register (only)
|>   D to E, current in original location (only).
|> 
|> This however misses the essential claim (lets hope I have this
|> paraphrase right):
|> That a variable whose home location is  at address 0x1234,
|> and which lives for possibly many short periods in a register,
|> is more compactly represented by
|>    a default location plus location lists describing
|>    times when the default location is not the current location
|> than by
|>    An explicit complete location list.
|
|Exactly what would be the description based on the proposal?
|
|How do you distinguish the cases where v is in two places (from B to C)
|from where it exists only in a register (from C to D)?  (It appears to
|me that the proposal does not anticipate the latter circumstance.)

Location lists allow one to describe a single variable
in any number of simultaneous locations.

A location list for the above could be:
	A to C   location 0x1234
	B to D   reg R
	D to E   location 0x1234
This describes the situation completely, including
the time when there is an overlap (2 locations).
Loclist entries zero and 1 overlap, location list entry 2
does not overlap anything.

The proposal defines a 'default' which only applies
if no location-list-entry applies.

The example above is not using such a default.


|> This claim based on implementation experience (it is not hypothetical).
|> 
|> The original proposal states that the space saved is significant.
|
|It would appear that your example would use a default location attribute
|and two location attributes.  Unless I'm missing something, this is not
|smaller.  If there are more occasions where you change the allocation for
|v, a location list entry is added in either case.  

I did not define a default, I was simply offering a non-default example.

Now I'll change to use default on the above case:

	default(for lifetime of v): location 0x1234
	loclist
		B to D  Register R
Note that this does NOT say the same thing a as the 3-entry 
loclist above, as the default proposal says that a valid
loclist *replaces* the default.   So there is no way
using defaults to specify multiple locations for a variable.
One can only use loclists for that.
One could do
	default(for lifetime of v): location 0x1234
	loclist
		B to C  location 0x1234
		B to D  Register R
to represent the same thing as the 3-entry-loclist.

The above is a pretty boring example,space-wise. 
Ron's original example
showed multiple short phases where the variable 'moved'
into Register R, not just one. 
Unless you have multiples the default is not profitable,
but that is up to a compiler to determine.

The motivation being:
  A global variable which, at various points in various
  functions, is moved to a register (for a while) is
  a specific pattern of use which is readily described
  by a default-plus-loclist in less space than
  when fully-described-by-loclist-alone.


|> The original proposal removes no capability of location lists.
|> 
|>   Aside:Note that if a vendor uses the proposed facility (as a vendor
|>         extension) debuggers not knowing about the facility
|>         are significantly impaired as they would ignore the default
|>         location.
|
|Yes, this would be an incompatible change.

Yes.

I think we've gotten to the point of understanding what
the proposal actually is now? 

This has certainly refreshed my memory of what loclists do :-)

The proposal adds nothing to what loclists do. 
It provides, for a specific sort of use pattern, a space saving.
At a cost in compatibility with previous dwarf2, as Michael 
notes.

davea@sgi.com