«

On 19-Mar-12 13:30, James Kuyper wrote:
> On 03/19/2012 01:55 PM, Stephen Sprunk wrote:
>> Indeed; this is a very basic optimization. Any decent compiler will try
>> to eliminate variables, where possible, and to store the ones it can't
>> in registers. Taking the address of a variable, though, forces that
>> variable to be stored in memory.
>
> Sort-of. Because of the as-if principle, &variable doesn't have to
> actually identify the location (if any) where the variable is stored
> unless some other part of the program would make the failure of the
> program to store it there detectable.
>
> For instance, if two non-overlapping objects have overlapping lifetimes,
> and the program prints out the values of pointers to those two objects,
> the print outs must identify different memory locations. If those
> addresses are compared for equality, they must compare unequal. If such
> a pointer is dereferenced, the behavior must be the same as if it
> actually pointed at the object it's supposed to refer to. However, if
> none of those things occur, printf("%p\n", (void*)&object) can print
> just about any arbitrary memory location that is not, detectably,
> currently in use for some other purpose, regardless of how (or whether)
> the variable is actually stored.

All of the above sounds reasonable, but when/why would any reasonably
sane implementation (i.e. not the DS9k) take advantage of that dubious
flexibility rather than use the "obvious" approach of storing the
variable in memory?

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

On 03/20/2012 04:52 AM, Stephen Sprunk wrote:
> On 19-Mar-12 13:30, James Kuyper wrote:
....
>> Sort-of. Because of the as-if principle, &variable doesn't have to
>> actually identify the location (if any) where the variable is stored
>> unless some other part of the program would make the failure of the
>> program to store it there detectable.
>>
>> For instance, if two non-overlapping objects have overlapping lifetimes,
>> and the program prints out the values of pointers to those two objects,
>> the print outs must identify different memory locations. If those
>> addresses are compared for equality, they must compare unequal. If such
>> a pointer is dereferenced, the behavior must be the same as if it
>> actually pointed at the object it's supposed to refer to. However, if
>> none of those things occur, printf("%p\n", (void*)&object) can print
>> just about any arbitrary memory location that is not, detectably,
>> currently in use for some other purpose, regardless of how (or whether)
>> the variable is actually stored.
>
> All of the above sounds reasonable, but when/why would any reasonably
> sane implementation (i.e. not the DS9k) take advantage of that dubious
> flexibility rather than use the "obvious" approach of storing the
> variable in memory?

Storing the variable in memory takes memory space and time; why bother
storing it there if you don't have to? A plausible implementation might
reserve a piece of memory to store the value in, if it actually needs to
be stored, and then find that it never actually needs to store the value
there. &variable would return that address, but the object never actual
resides in that memory. This doesn't sound like DS9K optimization to me.
--
James Kuyper

James Kuyper <> writes:

> Sort-of. Because of the as-if principle, &variable doesn't have to
> actually identify the location (if any) where the variable is stored
> unless some other part of the program would make the failure of the
> program to store it there detectable.

I know that I venture into the uncharted interiors of the vast tract
of C known as "implementation defined"...

But when I go there, I can tell you that I would be extremely upset,
if I found that my friendly optimizing compiler gave me a bogus buffer
address, even if the only usage thereof the compiler can detect, is to
enter it into the struct that defines a DMA transfer.

I would be doubly upset, if I found out that it only does this
optimization once in while.

--
/Wegge

Leder efter redundant peering af dk.*,linux.debian.*

On 03/20/2012 03:02 PM, Anders Wegge Keller wrote:
> James Kuyper <> writes:
>
>> Sort-of. Because of the as-if principle, &variable doesn't have to
>> actually identify the location (if any) where the variable is stored
>> unless some other part of the program would make the failure of the
>> program to store it there detectable.
>
> I know that I venture into the uncharted interiors of the vast tract
> of C known as "implementation defined"...
>
> But when I go there, I can tell you that I would be extremely upset,
> if I found that my friendly optimizing compiler gave me a bogus buffer
> address, even if the only usage thereof the compiler can detect, is to
> enter it into the struct that defines a DMA transfer.

DMA transfer is outside the scope of the C standard, so I didn't word my
statement quite right to cover that possibility, but that basically
falls under the category of "some other part of the program would make
the failure of the program to store it there detectable".

On 20-Mar-12 05:00, James Kuyper wrote:
> On 03/20/2012 04:52 AM, Stephen Sprunk wrote:
>> On 19-Mar-12 13:30, James Kuyper wrote:
> ...
>>> Sort-of. Because of the as-if principle, &variable doesn't have to
>>> actually identify the location (if any) where the variable is stored
>>> unless some other part of the program would make the failure of the
>>> program to store it there detectable.
>>>
>>> For instance, if two non-overlapping objects have overlapping lifetimes,
>>> and the program prints out the values of pointers to those two objects,
>>> the print outs must identify different memory locations. If those
>>> addresses are compared for equality, they must compare unequal. If such
>>> a pointer is dereferenced, the behavior must be the same as if it
>>> actually pointed at the object it's supposed to refer to. However, if
>>> none of those things occur, printf("%p\n", (void*)&object) can print
>>> just about any arbitrary memory location that is not, detectably,
>>> currently in use for some other purpose, regardless of how (or whether)
>>> the variable is actually stored.
>>
>> All of the above sounds reasonable, but when/why would any reasonably
>> sane implementation (i.e. not the DS9k) take advantage of that dubious
>> flexibility rather than use the "obvious" approach of storing the
>> variable in memory?
>
> Storing the variable in memory takes memory space and time; why bother
> storing it there if you don't have to? A plausible implementation might
> reserve a piece of memory to store the value in, if it actually needs to
> be stored, and then find that it never actually needs to store the value
> there. &variable would return that address, but the object never actual
> resides in that memory. This doesn't sound like DS9K optimization to me.

Hmm. My mental model of how a compiler works is slightly different: the
compiler initially locates all variables in memory and then (provided
various conditions are met) migrates some of them to registers or
eliminates them entirely. Taking the address of the variable would,
logically, prohibit such migration or elimination. Allocating addresses
for memory variables would be done (probably by the assembler) long
after that took place. Allocating addresses for variables that were
migrated or eliminated seems illogical.

(Perhaps that model is too simplistic, and I welcome correction, but so
far it has served me well enough to understand most optimizations.)

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

On 03/20/2012 05:47 PM, Stephen Sprunk wrote:
> On 20-Mar-12 05:00, James Kuyper wrote:
....
>> Storing the variable in memory takes memory space and time; why bother
>> storing it there if you don't have to? A plausible implementation might
>> reserve a piece of memory to store the value in, if it actually needs to
>> be stored, and then find that it never actually needs to store the value
>> there. &variable would return that address, but the object never actual
>> resides in that memory. This doesn't sound like DS9K optimization to me.
>
> Hmm. My mental model of how a compiler works is slightly different: the
> compiler initially locates all variables in memory and then (provided
> various conditions are met) migrates some of them to registers or
> eliminates them entirely. Taking the address of the variable would,
> logically, prohibit such migration or elimination. ...

The key point is that it is not the taking of the address that causes
such prohibition - it is using the address, or allowing it to be passed
somewhere where the compiler can't be sure it won't be used, that
actually triggers the prohibition.

> ... Allocating addresses
> for memory variables would be done (probably by the assembler) long
> after that took place. ...

The actual numerical address might not be allocated until later, but the
idea that an address might be needed can be recorded at an earlier stage
in the process.

> ... Allocating addresses for variables that were
> migrated or eliminated seems illogical. ...

So is code that takes an address without actually using it. But it's
precisely such code that I'm discussing. I'm mainly concerned with
whether or not such optimization is permitted, I'm less concerned with
whether or not there's a plausible way in which a reasonably-designed
implementation would produce such an optimization. But the key point is
that taking the address is not the right trigger - it's what happens to
that address that matters. If nothing "meaningful" happens to it, the
address doesn't have to mean anything real, and actual storage of the
value at the addressed location doesn't have to happen.

James Kuyper <> writes:

> On 03/20/2012 03:02 PM, Anders Wegge Keller wrote:

>> I know that I venture into the uncharted interiors of the vast tract
>> of C known as "implementation defined"...

...

> DMA transfer is outside the scope of the C standard,

I know, and I'm not trying to tell you otherwise.

> so I didn't word my statement quite right to cover that possibility,
> but that basically falls under the category of "some other part of
> the program would make the failure of the program to store it there
> detectable".

That would cover it.

--
/Wegge

Leder efter redundant peering af dk.*,linux.debian.*

On 20-Mar-12 17:37, James Kuyper wrote:
> On 03/20/2012 05:47 PM, Stephen Sprunk wrote:
>> Hmm. My mental model of how a compiler works is slightly different: the
>> compiler initially locates all variables in memory and then (provided
>> various conditions are met) migrates some of them to registers or
>> eliminates them entirely. Taking the address of the variable would,
>> logically, prohibit such migration or elimination. ...
>
> The key point is that it is not the taking of the address that causes
> such prohibition - it is using the address, or allowing it to be passed
> somewhere where the compiler can't be sure it won't be used, that
> actually triggers the prohibition.

Of course.

>> ... Allocating addresses for variables that were
>> migrated or eliminated seems illogical. ...
>
> So is code that takes an address without actually using it. But it's
> precisely such code that I'm discussing. I'm mainly concerned with
> whether or not such optimization is permitted, I'm less concerned with
> whether or not there's a plausible way in which a reasonably-designed
> implementation would produce such an optimization. But the key point is
> that taking the address is not the right trigger - it's what happens to
> that address that matters. If nothing "meaningful" happens to it, the
> address doesn't have to mean anything real, and actual storage of the
> value at the addressed location doesn't have to happen.

If nothing "meaningful" was done with the address, then presumably other
optimizations would eliminate the code that generated it, thus allowing
the compiler to migrate or eliminate the variable.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

On 03/21/2012 06:58 PM, Stephen Sprunk wrote:
> On 20-Mar-12 17:37, James Kuyper wrote:
....
>> implementation would produce such an optimization. But the key point is
>> that taking the address is not the right trigger - it's what happens to
>> that address that matters. If nothing "meaningful" happens to it, the
>> address doesn't have to mean anything real, and actual storage of the
>> value at the addressed location doesn't have to happen.
>
> If nothing "meaningful" was done with the address, then presumably other
> optimizations would eliminate the code that generated it, thus allowing
> the compiler to migrate or eliminate the variable.

I don't follow that - why would a situation that renders it unnecessary
to store a variable in addressable memory imply that it's unnecessary to
store it anywhere?
--
James Kuyper

On 21-Mar-12 19:24, James Kuyper wrote:
> On 03/21/2012 06:58 PM, Stephen Sprunk wrote:
>> On 20-Mar-12 17:37, James Kuyper wrote:
> ...
>>> implementation would produce such an optimization. But the key point is
>>> that taking the address is not the right trigger - it's what happens to
>>> that address that matters. If nothing "meaningful" happens to it, the
>>> address doesn't have to mean anything real, and actual storage of the
>>> value at the addressed location doesn't have to happen.
>>
>> If nothing "meaningful" was done with the address, then presumably other
>> optimizations would eliminate the code that generated it, thus allowing
>> the compiler to migrate or eliminate the variable.
>
> I don't follow that - why would a situation that renders it unnecessary
> to store a variable in addressable memory imply that it's unnecessary to
> store it anywhere?

Concrete example:

int quux(void)
{
int foo = 42;
int *bar = &foo;
return foo;
}

1. Both foo and bar start out in memory.
2. foo can't be migrated to a register because of the &foo.
3. bar is eliminated via dead code elimination.
4. foo can now be migrated to a register.
5. No address is needed for either foo or bar.

OTOH, say you have this:

#include <stdio.h>
int quux(void)
{
int foo = 42;
int *bar = &foo;
printf("%p\n", (void*)bar);
return foo;
}

1. Both foo and bar start out in memory.
2. foo can't be migrated to a register because of the &foo.
3. bar is migrated to a register.
4. An address is needed for foo but not for bar.

Can you give a similar example for what you're describing--and your
mental model of what a compiler would do with it?

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking