Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: addresses of variables |
| Date | 2012-03-22 06:22 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <jkeuhe$3df$1@dont-email.me> (permalink) |
| References | (8 earlier) <jkatt4$6h7$1@dont-email.me> <4F6906AC.9000509@verizon.net> <jkdmek$bit$1@dont-email.me> <jkdrfv$bos$1@dont-email.me> <jkeb80$dko$1@dont-email.me> |
On 03/22/2012 12:53 AM, Stephen Sprunk wrote:
> 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.
A prime example of a situation where neither foo, nor bar, nor the
address of foo, are needed.
> 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?
Yes, the second case you've just given fits what I'm talking about
exactly. Having recognized that there's absolutely no need to store 42
anywhere, the compiler reserves an arbitrary address for foo, but never
bothers storing anything at that address. That address is stored in a
register and passed to printf(), and is used for no other purpose. The
compiler need only ensure that the address is not used for any other
object that might have a lifetime that overlaps the call to quux(),
which is something it would have had to do anyway, if 42 had been stored
there.
If foo had static storage duration, there would be the possibility that
some other part of the code could ask the user to give foo's address
back to it, and then dereference a pointer to foo, which would make this
no longer a valid optimization. Because foo actually has automatic
storage duration, there's no possible way to write code which is
guaranteed to use that address during foo's lifetime, not even with
multi-threaded code.
Note: I'm winging it on that last statement. I've not had time to
assimilate C's new support for multi-threaded code. If there's some way
to guarantee that a scanf() call followed by a dereference in some other
part of the program will be executed between the printf() and the return
in quux(), then I'm wrong. But I'd expect that the ability to guarantee
such sequencing would require executing a call to one of the new
thread-related functions between the printf() and the return. Code where
such sequencing is merely possible, but not guaranteed, has undefined
behavior if it doesn't execute in that sequence, thereby allowing the
optimization.
--
James Kuyper
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
addresses of variables Zero <chefmuetze@web.de> - 2012-03-18 03:56 -0700
Re: addresses of variables "BartC" <bc@freeuk.com> - 2012-03-18 11:18 +0000
Re: addresses of variables jt@toerring.de (Jens Thoms Toerring) - 2012-03-18 11:18 +0000
Re: addresses of variables pete <pfiland@mindspring.com> - 2012-03-18 07:30 -0500
Re: addresses of variables Zero <chefmuetze@web.de> - 2012-03-18 04:42 -0700
Re: addresses of variables Lowell Gilbert <lgusenet@be-well.ilk.org> - 2012-03-19 10:52 -0400
Re: addresses of variables Stephen Sprunk <stephen@sprunk.org> - 2012-03-19 12:55 -0500
Re: addresses of variables James Kuyper <jameskuyper@verizon.net> - 2012-03-19 14:30 -0400
Re: addresses of variables jacob navia <jacob@spamsink.net> - 2012-03-19 20:11 +0100
Re: addresses of variables hoganlong@gmail.com - 2012-03-19 12:17 -0700
Re: addresses of variables James Kuyper <jameskuyper@verizon.net> - 2012-03-19 16:15 -0400
Re: addresses of variables hoganlong@gmail.com - 2012-03-19 14:18 -0700
Re: addresses of variables "io_x" <a@b.c.invalid> - 2012-03-19 23:26 +0100
Re: addresses of variables Stephen Sprunk <stephen@sprunk.org> - 2012-03-20 03:52 -0500
Re: addresses of variables James Kuyper <jameskuyper@verizon.net> - 2012-03-20 06:00 -0400
Re: addresses of variables Stephen Sprunk <stephen@sprunk.org> - 2012-03-20 16:47 -0500
Re: addresses of variables James Kuyper <jameskuyper@verizon.net> - 2012-03-20 18:37 -0400
Re: addresses of variables Stephen Sprunk <stephen@sprunk.org> - 2012-03-21 17:58 -0500
Re: addresses of variables James Kuyper <jameskuyper@verizon.net> - 2012-03-21 20:24 -0400
Re: addresses of variables Stephen Sprunk <stephen@sprunk.org> - 2012-03-21 23:53 -0500
Re: addresses of variables James Kuyper <jameskuyper@verizon.net> - 2012-03-22 06:22 -0400
Re: addresses of variables Kenneth Brody <kenbrody@spamcop.net> - 2012-03-22 12:01 -0400
Re: addresses of variables Stephen Sprunk <stephen@sprunk.org> - 2012-03-24 16:09 -0500
Re: addresses of variables Jens Gustedt <jens.gustedt@loria.fr> - 2012-03-23 13:41 +0100
Re: addresses of variables James Kuyper <jameskuyper@verizon.net> - 2012-03-23 09:06 -0400
Re: addresses of variables Jens Gustedt <jens.gustedt@loria.fr> - 2012-03-23 19:47 +0100
Re: addresses of variables James Kuyper <jameskuyper@verizon.net> - 2012-03-23 16:04 -0400
Re: addresses of variables Jens Gustedt <jens.gustedt@loria.fr> - 2012-03-24 00:19 +0100
Re: addresses of variables James Kuyper <jameskuyper@verizon.net> - 2012-03-23 22:20 -0400
Re: addresses of variables Jens Gustedt <jens.gustedt@loria.fr> - 2012-03-24 09:39 +0100
Re: addresses of variables Anders Wegge Keller <wegge@wegge.dk> - 2012-03-20 20:02 +0100
Re: addresses of variables James Kuyper <jameskuyper@verizon.net> - 2012-03-20 15:18 -0400
Re: addresses of variables Anders Wegge Keller <wegge@wegge.dk> - 2012-03-21 21:37 +0100
Re: addresses of variables Lowell Gilbert <lgusenet@be-well.ilk.org> - 2012-03-20 11:52 -0400
Re: addresses of variables Kenneth Brody <kenbrody@spamcop.net> - 2012-03-21 11:04 -0400
csiph-web