lkml.org 
[lkml]   [1998]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: A patch for linux 2.1.127
"Peter T. Breuer" wrote:
> "A month of sundays ago Steven Roberts wrote:"
> > Isn't that what the "inline" keyword is for???
>
> Sort of. It's for when you know beyond a shadow of a doubt that something
> should work best inline. But I generate code, I don't write it. Maybe if
> I read the output code I'd be able to make sensible decisions about what to
> inline and what not to, but I certainly don't and the people who use my code
> generator don't. I do emit a few "inlines" but I generally would have
> to duplicate gcc's calculations in order to tell it to inline when it
> should anyway have inlined just by virtue of being asked to optimize.
> I'm not going to do that.
>
I think the main point is, it really doesn't matter if egcs tries to do
auto-magic inlining, it did it wrong in the case that started this
thread, and if it has troubles doing it, it should not try.

I also agree with a bunch of folks on here who feel that having the
compiler try to figure out what should be inlined is probably not a goog
idea. situations like:

static void slow_foo(int stuff)
{
// code that shouldn't be bothered with inline
}

static inline void foo(int stuff)
{
if (foo_needed)
slow_foo(stuff);
}

Now I can easily see where a compiler doing auto-inlining could try to
do both inline. I guess I consider that level of optimization best left
to the programmer. You can't try to have a compiler do everything, good
programers have to have good smart programmers working on them.

Regards,
Steve Roberts

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.053 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site