This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: Inline limits

From: Steven Bosscher <stevenb dot gcc at gmail dot com>
To: Paul Brook <paul at codesourcery dot com>
Cc: gcc at gcc dot gnu dot org, Richard Guenther <rguenther at suse dot de>, Richard Guenther <richard dot guenther at gmail dot com>, Hariharan <hariharans at picochip dot com>, jh at suse dot cz
Date: Thu, 5 Feb 2009 15:10:54 +0100
Subject: Re: Inline limits
References: <497DE4D3.2090104@picochip.com> <200902051351.30911.paul@codesourcery.com> <alpine.LNX.2.00.0902051455110.11836@zhemvz.fhfr.qr> <200902051404.54138.paul@codesourcery.com>

On Thu, Feb 5, 2009 at 3:04 PM, Paul Brook <paul@codesourcery.com> wrote:
>> Hmm, we should be able to model this counting the number of edges
>> bypassing the call, right?
>
> Something like that, yes.
>
> Ideally you'd want to factor in the size of the function, and the current
> length of those edges, at which point you've probably got sufficient
> information to make bb-reorder fix the problem once and for all ;-)

I haven't read the thread in full, so maybe someone already mentioned
it...  You do know bb-reorder is completely disabled for -Os, right?

Gr.
Steven

References:
- Re: Inline limits
  - From: Paul Brook
- Re: Inline limits
  - From: Richard Guenther
- Re: Inline limits
  - From: Paul Brook

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]