public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Daniel Berlin <dan@cgsoftware.com>
To: dewar@gnat.com
Cc: carlo@alinoe.com, dan@cgsoftware.com, gcc@gcc.gnu.org
Subject: Re: Inlining heuristics for C++
Date: Mon, 09 Jul 2001 22:17:00 -0000	[thread overview]
Message-ID: <87lmlxmkh0.fsf@cgsoftware.com> (raw)
In-Reply-To: <20010710044938.BC12EF2B12@nile.gnat.com>

dewar@gnat.com writes:

> <<to thank you for writing this (I mean that).  I am reassured too, that
> functions marked as inline still WILL be inlined.  If you add point 2)
>>>
> 
> Personally, I don't feel that such reassurance is necessary. Obviously
> a compiler is not required to inline things that are marked as inlined
> (since basically inlining is semantically neutral). It is perfectly
> reasonable for a compiler to take an inlining request as basically
> a request to inline *if* time performance is improved, I think it is
> always fine for a compiler to ignore an inlining request if inlining
> would be detrimental to both time and space performance.

Hopefully, Diego's tree optimizer work will start to clear the way
towards doing smart inlining (based on static or real profiling info).
And for the loop cases, we can do procedure cloning anyway (clone the
procedure to a new name, with the constant arguments set constant, and
make the loop/anything else with those arguments call the new
procedure).




-- 
"I watched the Indy 500, and I was thinking that if they left
earlier they wouldn't have to go so fast.
"-Steven Wright

  reply	other threads:[~2001-07-09 22:17 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-09 21:49 dewar
2001-07-09 22:17 ` Daniel Berlin [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-07-10 14:53 mike stump
2001-07-10 15:04 ` Daniel Berlin
     [not found] <87r8vpo8rw.fsf@cgsoftware.com.suse.lists.egcs>
     [not found] ` <20010710122244.A14584@hg.cs.mu.oz.au.suse.lists.egcs>
2001-07-10  2:42   ` Andi Kleen
2001-07-10 14:16     ` Hartmut Schirmer
2001-07-11 14:27       ` Fergus Henderson
2001-07-09 20:13 dewar
2001-07-09 20:23 ` Joe Buck
2001-07-09 18:47 Daniel Berlin
2001-07-09 19:22 ` Fergus Henderson
2001-07-09 20:18   ` Daniel Berlin
2001-07-09 23:30   ` Mark Mitchell
2001-07-09 19:56 ` Carlo Wood
2001-07-09 20:31   ` Daniel Berlin
2001-07-09 21:05     ` Carlo Wood
2001-07-09 21:26       ` Daniel Berlin
2001-07-09 21:45         ` Carlo Wood
2001-07-09 20:05 ` Timothy J. Wood
2001-07-09 20:34   ` Daniel Berlin
2001-07-09 23:26 ` Mark Mitchell
2001-07-09 23:37   ` Daniel Jacobowitz
2001-07-10  0:00   ` Fergus Henderson
2001-07-10  0:13     ` Daniel Berlin
2001-07-10  0:09   ` Daniel Berlin
2001-07-10  0:20   ` Daniel Berlin
2001-07-10  0:30   ` Daniel Berlin
2001-07-10  2:47   ` Nathan Sidwell

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=87lmlxmkh0.fsf@cgsoftware.com \
    --to=dan@cgsoftware.com \
    --cc=carlo@alinoe.com \
    --cc=dewar@gnat.com \
    --cc=gcc@gcc.gnu.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).