This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] [4.0] Fix performance regressions due to inlining
- From: Paul Schlie <schlie at comcast dot net>
- To: Richard Earnshaw <rearnsha at gcc dot gnu dot org>
- Cc: Richard Sandiford <rsandifo at redhat dot com>,Steven Bosscher <stevenb at suse dot de>,Patch List <gcc-patches at gcc dot gnu dot org>,Mark Mitchell <mark at codesourcery dot com>,Richard Guenther <rguenth at tat dot physik dot uni-tuebingen dot de>
- Date: Tue, 08 Mar 2005 13:45:10 -0500
- Subject: Re: [PATCH] [4.0] Fix performance regressions due to inlining
> From: Richard Earnshaw <rearnsha@gcc.gnu.org>
>> On Tue, 2005-03-08 at 14:18, Paul Schlie wrote:
>> - yes, they tend to favor minimizing code size; which underestimating
>> instructions works against, resulting in more code being in-lined tending
>> to result in fatter code; also note that 2-operand ISA's tend to be less
>> deeply pipelined, likely because their goal isn't performance but
>> efficiency, therefore they also tend ironically benefit less from
>> aggressive in-lining than more deeply pipelined machines do.
>
> That over-simplifies things (at least on ARM). ARM's 'high-performance'
> cores still support the Thumb ISA.
- yes, but presumably only invoked when compactness is desired over
performance, as I recall that the two modes are not freely intermixed
without an explicit mode switch between the two? (but acknowledge your
point) I was just fishing for a possibly simple means by which some
indication may be provided by the target to affect the relative
interpretation of instruction count/cost heuristic estimates when used
to guide unrolling and/or in-lining decisions.