lkml.org 
[lkml]   [2006]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 00/2] improve .text size on gcc 4.0 and newer compilers
On Mon, Jan 02, 2006 at 11:41:24AM -0800, Linus Torvalds wrote:
> > Where does this certainity come from? gcc-3.x (as well as 2.x) each had
> > its own heuristics which functions should be inlined and which should not.
> > inline keyword has always been a hint.
>
> NO IT HAS NOT.
>
> This is total revisionist history by gcc people. It did not use to be a
> hint. If you asked for inlining, you got it unless there was some
> technical reason why gcc couldn't inline it (ie recursive inlining, and
> trampolines and some other issues). End of story.

One of the "technical reasons" was if the function was bigger than some
threshold. And in that case I think it is ok to speak about inline keyword
as a hint. The default inline limit (in rtx count after constant folding,
but not other optimizations) was bigger than in the GCC 3.x era, sure, but
there was a limit and GCC wasn't inlining functions bigger than that limit,
even if they could be simplified due to constant arguments to something
much smaller.

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

\
 
 \ /
  Last update: 2006-01-02 21:32    [W:0.110 / U:0.336 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site