On Wed, 18 Jul 2007, Roland Dreier wrote:
>
> BTW, I noticed one interesting thing while starting on this cleanup.
> I wanted to make sure that the generated code didn't change with the
> first step, and I actually discovered that the patch below seems to
> make the generated code *better*, maybe because some gcc alias
> analysis doesn't get as paranoid without the void *:
Absolutely.
The way to get pretty much any compiler to generate better code is:
- code it simply
- don't have tons of variables with overlapping lifetime
- use limited-scope variables (ie don't have the variables at the
outermost scope, declare them in the smallest scope you can)
and trying to split things up into functions helps all of these.
In fact, you can often get better code even when the functions aren't even
inlined, because of the "simpler code" issue. Gcc sometimes tries to be
too clever with its CSE etc, and generates really nasty complex code with
lots of register spills, just because it keeps stuff live rather than just
regenerating them.
So inlining a function doesn't even make it faster, all the time. You want
to inline when
- the function is so small that the call is literally a big part of it,
and it doesn't even need more than a couple of registers, so the
calling convention has more register pressure than inlining the
function itself would have.
OR
- the callers tend to have constant arguments that can benefit from
constant folding inside the function
but inlining in many other circumstances actually generates *worse* code
and just makes debugging harder and the I$ footprint bigger.
> And here's the patch itself -- I think this is a reasonable size step
> to break things up into. I assume that this is the basic form of the
> cleanup that you're proposing?
Yes, this looks good. Doing these kinds of things for the various other
things is likely to make the code more readable, and as you already found
out, the generated code doesn't tend to be worse either. It might not
_always_ be a win size and performance-wise, but it can be, and so
readability should generally always be the #1 goal, because quite often it
actually does help the compiler too.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
