This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [ast-optimizer-branch]: Inlinability checks
- To: Richard Henderson <rth at redhat dot com>
- Subject: Re: [ast-optimizer-branch]: Inlinability checks
- From: Nathan Sidwell <nathan at codesourcery dot com>
- Date: Tue, 24 Jul 2001 09:03:52 +0100
- CC: gcc-patches at gcc dot gnu dot org
- Organization: Codesourcery LLC
- References: <3B5BEC0E.D2244D1D@codesourcery.com> <20010723124017.B17541@redhat.com>
Richard Henderson wrote:
>
> On Mon, Jul 23, 2001 at 10:19:10AM +0100, Nathan Sidwell wrote:
> > ! else if (TREE_CODE (t) == ADDR_EXPR
> > ! && TREE_CODE (TREE_OPERAND (t, 0)) == LABEL_DECL)
> > ! reason = N_("takes address of label");
>
> This is inlinable. Where did you get this notion?
integrate.c has the following,
if (forced_labels)
return
N_("function with label addresses used in initializers cannot inline");
which, I admit, is not exactly the same as just taking the address
of a label -- I don't understand why initializers are special. Thinking
more about this, any well-formed routine taking label addresses must
also have a computed goto (so what is integrate.c saying here?)
Is my patch wrong, or just over pessimistic here?
thanks for looking at this.
nathan
--
Dr Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC
'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org