This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Inlining and estimate_num_insns
- From: Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>
- To: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- Cc: Mark Mitchell <mark at codesourcery dot com>,Jan Hubicka <hubicka at ucw dot cz>, Steven Bosscher <stevenb at suse dot de>,Jan Hubicka <jh at suse dot cz>, <gcc at gcc dot gnu dot org>, <gp at suse dot de>
- Date: Mon, 28 Feb 2005 09:50:06 +0100 (CET)
- Subject: Re: Inlining and estimate_num_insns
On 27 Feb 2005, Gabriel Dos Reis wrote:
> Mark Mitchell <mark@codesourcery.com> writes:
>
> | 5. However, it really might be sensible to have the C++ front end
> | treat "inline" as a command, rather than a hint, by default. It might
>
> For "simple enough" functions. Here, by "simple enough" function, I
> mean a metric that uses counts very close to program source level, not
> insns (in particular we must pay special attention not to artificially
> inflate the measuring by most temporaries introduced by tree-ssa and
> such.)
Yes, the patch tries to address exactly this issue by ignoring stores
to DECL_IGNORED variables. As a side-effect ...
[...]
> In-class definitions of inline functions is very common for small
> functions -- typically trivial accessors. The artificial distinction
> you're making does not make much sense to me, for practical purposes.
... these accessor functions get inlined with the same size accounting
as if you wrote their function body in place of the function call.
> I do agree that measurements are necessary.
Of course - and even more if we want to consider doing anything for 4.0.
Richard.
--
Richard Guenther <richard dot guenther at uni-tuebingen dot de>
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/