Re: Compiler Optimisation?

[albaugh@agames.com (Mike Albaugh)]

Thomas W. Christopher (tc@charlie.cns.iit.edu) wrote:
: How much faster does optimized code run for different optimizations?

: I believe Daniel Bidwell ( http://www2.andrews.edu/~bidwell/ ) worked
: on that question in his PhD dissertation, as well as how much do the
: optimizations cost.

: As I recall, he found that "folding," performing constant arithmetic at
: compile time, not only makes the compiled code run faster, but also the
: compiler.

	Perennial grump here. :-) In at least one case (gcc from at
least 1.31 to when I stopped bothering to look, 2.mumble) "folds"
structure member accesses inapropriately, so that "letting a function
know" what the value of a structure pointer is can produce much worse
code.  I would expect that if they don't fix this and start in-lining
really aggressively, code performance could deteriorate unexpectedly
as the inliner "gets smarter" and enlarges the scope of "knowledge".

	In case I have been too terse, what I'm talking about is:

static struct foo {
	int a;
	int b;
	int c;
} myfoo;

int foosum() {

	struct foo *myfp = &myfoo;

	return myfp->a + myfp->b + myfp->c;
}

gcc (often) generates code as if that last line was:

	return myfoo.a + myfoo.b + myfoo.c;

(or more pedantically, as if the whole expression was "flattened" into
a nasty mess of casts to int pointers with constant offsets)

	In the _best_ case, this simply turns a pointer-load and three
(base+disp) instructions into three 32-bit-address instructions.  On
some machines, it gets even worse. In theory, the compiler _could_
recognize the common expression and re-generate the pointer form, but
a) it apparently doesn't and b) to do so would take time, so the
folding, at least in this case, would not be making the compiler
itself faster.

	Not to say that "folding is bad", but rather "Optimizations
can interact, there is no free lunch" :-)
						Mike
| albaugh@agames.com, speaking only for myself