Re: Modifies vs. Replaces

[Jim Dehnert <dehnert at transmeta dot com>]

Michael Eager wrote:
> 
> 
> What I seem not to be able to convey is that you are describing an
> implementation.  Rather than stating what the information represents,
> you give an algorithm which the consumer is to follow.
> 
> I'm of the opinion that the text in 2.4.5 is adequate.

And this is why you get the impression that we're talking about implementation.
The current text is not adequate to unambiguously describe the situation where
there are "holes" in the allocation of a variable to its home location (e.g.
that specified by a global's defining instance's location info).  We keep
talking about implementation to attempt to demonstrate the problem to you,
since you show no signs of understanding it.  Now I assume that you do, in
fact, understand, and either (a) don't care, (b) prefer to do nothing about
it for some reason, or (c) think it's acceptable to have an ambiguous spec
and leave it to each implementation to deal with the ambiguity via its own
(unspecified) interpretation or extensions.  You haven't told us which, so
we'll have to speculate until you do.  Several of us, however, believe
this is a real, important problem in current compilers, and prefer to have
an unambiguous Dwarf specification of how compilers can describe the situation.
I for one don't care if we deal with some of the extended hypothethical
optimization cases that have been described, but I do know of compilers
that allocate memory variables temporarily (but for extended ranges) to
registers, I think it's important to deal with this, and I think after our
discussion that we know how (and it's not hard).

To repeat, the fundamental reason the current specification won't deal
correctly with reallocation of memory variables to memory is that it says
that all locations in a list are equivalent.  So a producer has no standard
way to tell the consumer which one to fetch a value from if there are multiple
locations listed for a given address, so it must create a large set of disjoint
location lists.  This was an efficiency issue in the case of our earlier
discussion about default values.  It becomes a correctness issue if we allow
locations with non-defining instances of globals to augment those of the
defining instance, and expect the latter to have one all-inclusive range
for the home location in static memory.  Perhaps you think there's a better
way that avoids these problems.  If so, by all means describe it.

I think we can deal with this issue by extending your change slightly:

> If additional
> text is desired, then perhaps a small change to the text of my proposal
> would be reasonable (second paragraph under item 3):
> 
> Change
>         If the object is a non-defining declaration, the location
>         specified modifies the location specified by the defining
>         declaration and is only valid for the scope of the current
>         declaration.
> to
>         If the object is a non-defining declaration, the location(s)
>         specified provides additional location(s) for the object in
>         addition to those specified by the defining declaration and
>         is only valid for the scope of the current declaration.

--------- Only the first location listed from the non-defining declaration's
	  list for a particular address is guaranteed to contain the object's
	  value.  Copies in all locations, from both the non-defining and the
	  defining declaration, may be live.  (And must therefore be updated
	  if a consumer is updating, but that's a statement about consumers.)

I would prefer, incidently, to make the same statement about simple location
lists that aren't unions of defining and non-defining instances, because it
would solve the same problem in that case without requiring full lists for
disjoint ranges.

Jim

-- 
-	    Jim Dehnert		dehnert@transmeta.com
	    (408)919-6984	dehnertj@acm.org