public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin LaHaise <bcrl@kvack.org>
To: "J.A. Magallón" <jamagallon@ono.com>
Cc: "Linux-Kernel, " <linux-kernel@vger.kernel.org>
Subject: Re: Inlining can be _very_bad...
Date: Wed, 28 Mar 2007 21:29:55 -0400	[thread overview]
Message-ID: <20070329012955.GD17334@kvack.org> (raw)
In-Reply-To: <20070329011838.6e832615@werewolf-wl>

On Thu, Mar 29, 2007 at 01:18:38AM +0200, J.A. Magallón wrote:
> It looks like is updating the stack on each iteration...This is -march=opteron
> code, the -march=pentium4 is similar. Same behaviour with gcc3 and gcc4.
> 
> tst.c and Makefile attached.
> 
> Nice, isn't it ? Please, probe where is my fault...

Yes, gcc sucks in its handling of large return values, news at 11.  I have 
several outstanding bugs on cases where gcc could keep things in registers 
but doesn't.

That said, it tends to do much better on plain integer code, as that is 
what it gets tuned for.  Do NOT propagate the blanket myth that inlining is 
a bad thing.  It is very useful for small functions where the overhead 
associated with call/ret sequences and register clobbers overshadows the 
work being done.  The call/ret updates alone can make a big difference when 
there are lots of other (more useful) memory transactions to complete.  Take 
a look at things like the notifier hooks for an example of something that 
does far too little work per function call and should really be inlined.

		-ben
-- 
"Time is of no importance, Mr. President, only life is important."
Don't Email: <zyntrop@kvack.org>.

  reply	other threads:[~2007-03-29  1:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-28 23:18 Inlining can be _very_bad J.A. Magallón
2007-03-29  1:29 ` Benjamin LaHaise [this message]
2007-03-29 17:52 ` Adrian Bunk
2007-03-29 22:01   ` J.A. Magallón
2007-03-29 22:28     ` Adrian Bunk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070329012955.GD17334@kvack.org \
    --to=bcrl@kvack.org \
    --cc=jamagallon@ono.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox