This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] computed gotos
- From: Jan Hubicka <jh at suse dot cz>
- To: Brad Lucier <lucier at math dot purdue dot edu>
- Cc: gcc-patches at gcc dot gnu dot org, dberlin at dberlin dot org, law at redhat dot com
- Date: Fri, 24 Jan 2003 22:40:15 +0100
- Subject: Re: [tree-ssa] computed gotos
- References: <200301242136.h0OLaYf27355@banach.math.purdue.edu>
> Re:
>
> > On Friday, January 24, 2003, at 03:09 PM, law@redhat.com wrote:
> >
> > > This allows us to handle computed gotos in the presense of static
> > > initializers containing label addresses. Fun fun.
> >
> > If you actually want to *simplify* computed gotos (whose labels are
> > local to the function), you can transform them into a switch statement
> > by assigning each label whose address is taken some small integer number.
>
> The Gambit-C Scheme->C compiler can generate code that contains
> either computed gotos or a large switch, and the computed goto code
> can be up to 50% faster on some architectures. So if you're saying
> that computed gotos should be converted internally to switches and
> compiled that way, I think that is a bad idea in some circumstances.
My experience is that this is usually done to basically save jumps to
the switch in interpreters (like interpeter.cc in our Java runtime).
This should be solved by teaching GCC to duplicate code when it results
in saving some jumps. BB-reorder on RTLOPT branch does that. I would
be curous how that affers the relavie score of computed gotos and
switches.
Honza
>
> Brad