This is the mail archive of the
mailing list for the GCC project.
Re: inline functions and local labels
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>, rth at cygnus dot com
- Subject: Re: inline functions and local labels
- From: Richard Henderson <rth at cygnus dot com>
- Date: Tue, 28 Jul 1998 03:57:40 -0700
- Cc: egcs-patches at cygnus dot com, gcc2 at cygnus dot com
- References: <9807281041.AA05463@vlsi1.ultra.nyu.edu>
- Reply-To: Richard Henderson <rth at cygnus dot com>
On Tue, Jul 28, 1998 at 06:41:16AM -0400, Richard Kenner wrote:
> I'm confused. How can deciding *not* to inline a function cause
> problems? Inlining has no semantic consequences. It isn't valid in C
> to do anything that relies on functions being inlined.
The construct is used in a couple of functions used throughout the network
stack. Failing to inline has a disasterous performance impact.
> True, in this case. But the point is that GCC will still be doing the wrong
> thing with the labels, by not duplicating them.
Eh? I thought that was what inline_remap.label_map was for. In which
situation are labels not being duplicated, and I'll fix it.
> But when there are just the addresses of labels, we produce confusing
Indeed. We will probably eliminate the construct at some point in the
future (as the mere existance of the labels inhibits optimization), but
as we've gone into code-freeze for a release, it will not happen soon.
So I am quite interested in doing what needs to be done to ensure that
this can continue to work.