Re: learning dragonfly or C...
:> struct fubar *blah;
:> struct fubar *nblah;
:>
:> getmafubar(&nblah);
:> blah = nblah;
:>
:> blech = blah->this + blah->that - somefunction(blah);
:> and_other_random_things_using(blah);
:>
:> blah blah blah...
:>
:If it's not to protect *blah memory from illegal getmafubar() data,
:then my next guess is a debugging trap, so if getmafubar() fails, &blah
:will retain state data from before the error? (not so subtle hint at
:checkpt.c line 487)
:
:// George
:
Nope. Ok, I'll tell you... it's so the compiler can optimize 'blah'
into a register.
You see, if you pass the address of a local variable to a procedure,
or in most cases take the address of a local variable at all, the
compiler has no idea whether that address will be stored persistently
by that procedure and the contents of the variable then modified as
a side effect to other unrelated procedure calls. This means that the
compiler cannot safely leave that variable into a register, not even
if you compile -O3. If the compiler ever loads the variable into a
register to do arithmatic on it, it cannot retain the register to cache
the value across the next procedure call or many other code constructs.
So the purpose of the above is to allow the compiler to optimize the
code generation in the rest of the routine.
For example, take this program:
main()
{
int y;
int x;
#ifdef SPECIAL
fubar(&y);
x = y;
#else
fubar(&x);
#endif
++x;
++x;
bleh(x);
++x;
++x;
bleh(x);
}
And try compiling like this (and make your xterm tall):
setenv CCVER gcc34
cc -S -O3 x.c
cat x.s
And compare it against (in another xterm window beside the first one):
setenv CCVER gcc34
cc -S -DSPECIAL -O3
cat x.s
Notice how poorly it optimizes the first version verses how well
it optimizes the SPECIAL version.
-Matt
Matthew Dillon
<dillon@backplane.com>
討論串 (同標題文章)
完整討論串 (本文為第 12 之 23 篇)：