Related articles |
---|
Gotos jhallen@wpi.wpi.edu (1989-11-12) |
Re: Gotos preston@rice.edu (Preston Briggs) (1989-11-13) |
Re: Gotos bright@dataio.Data-IO.COM (1989-11-17) |
From: | jhallen@wpi.wpi.edu (Joseph H Allen) |
Newsgroups: | comp.compilers |
Date: | 12 Nov 89 16:09:44 GMT |
From: | jhallen@wpi.wpi.edu (Joseph H Allen) |
Organization: | Worcester Polytechnic Institute, Worcester, Mass. |
How much of an effect do gotos have on register and other optimization
techniques? In particular, do C optimizing compilers take a simple minded
view towards gotos or does data flow analysis actually follow goto paths?
The reason I ask is, I know some compilers (WATCOM C compiler on IBM PCs I
think is one) combine common endings:
if( )
{
XXX
YYY <-------+----- These don't get duplicated
return; |
} |
else |
{ |
ZZZ |
YYY <-------+
return;
}
But mine doesn't. So is it better to just let the code be duplicated or
is it o.k. to use gotos to prevent the duplication:
if( )
{
XXX
goto here;
}
else
{
ZZZ
here:
YYY
return;
}
(Please ignore the fact that for this example you can just move the 'YYY
return' outside the if construct. Assume that it is a more complicated case
where you just can't do that)
Joe
[Depends on the compiler; I've seen some that depend on loops in the source
code and punt if gotos change it at all, and I've seen others that turn
everything into low-level gotos in intermediate code and then rediscover the
control structure from that. Comments from actual compiler writers are
welcome. The last C compiler I wrote was the original PCC for the RT PC and
it avoided the problem by doing almost no optimization at all. The assembler
postpass did tail merging, but at the time we hadn't ported it. -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.