Gotos

jhallen@wpi.wpi.edu (Joseph H Allen)
12 Nov 89 16:09:44 GMT

          From comp.compilers

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)
| List of all articles for this month |

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]





Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.