In article <1105616366.102443.258700@c13g2000cwb.googlegroups .com>
joshc <josh.curtz@gmail.com> wrote:[color=blue]
>... I realized this was probably better suited for comp.compilers
>and that's why minutes after I posted I tried to use the "remove"
>option but I guess somehow my message was still posted to the group.[/color]
(Newsgroup postings are generally not cancel-able at all anymore,
because vandals used to use the feature to remove everything from
some or all newsgroups.)
[color=blue]
>I realize that the optimizations that I asked about have nothing to do
>with the standard. I simply wanted to see whether or not any compilers
>out there do what I was asking about more as a question to educate
>myself about compilers.[/color]
Many compilers do various kinds of optimizations. :-)
[color=blue]
>... when I was reading the GCC manual regarding the inline keyword
>it [noted aspects of optimizing inline-expanded functions]. ... It
>seemed to imply that this happened because of using the 'inline'
>keyword so I was wondering if I picked up on that correctly or if
>that kind of optimization also happened in functions that are _not_
>inlined.[/color]
In general, this kind of optimization can only happen if the
body of the function is expanded in line in the caller (because
the constraints on the operands are not known at compile time
in the other case). But gcc will sometimes do in-line expansion
of functions even when they are *not* declared "inline"; and as
it happens, Diab does even-more-aggressive function inlining than
gcc, in general.
Even in C90 (which has no "inline" keyword), you can "encourage"
a compiler to in-line-expand a short function by defining it before
calling it:
/* the "static" here is optional but generally good */
static int f(int x) {
return x + 1;
}
...
void g(args) {
...
result = f(1);
...
}
A practical C compiler *has* to read source code "top to bottom", as
it were, starting at the beginning of the source file and ending at
the end. Because of this, it will have "seen" all of f() by the time
it gets to compiling g(). If f() is small (as here), and the compiler
does this kind of optimization at all, there is a good chance it will
remove the call and, in this case, just do "result = 2".
Note that by making f() static, f() becomes invisible to other
translation units (roughly, "source files"), so not only can the
compiler expand calls to f() in line, it can also not bother
generating any actual function f() in the first place. This also
allows you to violate the usual rules about C code, and put the
entire function f() in a header file that gets included in multiple
translation units. (If the compiler does *not* do inline expansion
and optimizations, this will waste code space in the final executable,
but still *work* OK.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it
http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
