Messages in this thread | | | Date | Wed, 11 Nov 1998 16:39:50 -0800 | From | Steven Roberts <> | Subject | Re: 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/
| |