Re: [tree-ssa] computed gotos

[Jan Hubicka <jh at suse dot cz>]

> 
> On Friday, January 24, 2003, at 04:36  PM, Brad Lucier wrote:
> 
> >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,
> What does the switch look like?
> Can you hand me some code where the performance depends on the use of 
> computed gotos?
> I'll run it through CIL (which *does* the transformation), and see if 
> it is, indeed slower.
> >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.
> >
> 
> The idea of GIMPLE is to remove language specificness wherever possible.
> The Computed gotos extensions we have are specific to C, and unless 
> it's going to make things a lot slower, they should be transformed into 
> some non-language specific construct.

On the other hand the computed gotos are fairly low level construction
and makes sense to be supported by the compiler, even when it is
nasty feature especially because it makes huge CFG I have to work around
all the time :)

I remember seeing computed gotos to come out of f77 frontend too.

Honza
> 
> If it *will* make things a lot slower, of course, then i wouldn't want 
> to do it without a lot heavier justification.
> 
> Thus, it would be helpful to be able to benchmark code, rather than 
> theorize.
> 
> >Brad