Re: learning dragonfly or C...

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:>	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@xxxxxxxxxxxxx>