This is the mail archive of the
gcc-patches@gcc.gnu.org
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
> results.
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.
r~