Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| Loop Optimizations and Gotos jra@gensym.com (1995-11-08) |
| Re: Loop Optimizations and Gotos burley@cygnus.com (1995-11-12) |
| Loop Optimizations and Gotos dave@occl-cam.demon.co.uk (Dave Lloyd) (1995-11-12) |
| Re: Loop Optimizations and Gotos cliffc@ami.sps.mot.com (1995-11-13) |
| Re: Loop Optimizations and Gotos cdg@nullstone.com (1995-11-13) |
| Re: Loop Optimizations and Gotos faiman@zko.dec.com (1995-11-16) |
| Re: Loop Optimizations and Gotos hrubin@stat.purdue.edu (1995-11-17) |
| Re: Loop Optimizations and Gotos j-grout@glibm9.cen.uiuc.edu (1995-11-17) |
| Re: Loop Optimizations and Gotos baynes@ukpsshp1.serigate.philips.nl (1995-11-20) |
| [8 later articles] |
| Newsgroups: | comp.compilers |
| From: | Dave Lloyd <dave@occl-cam.demon.co.uk> |
| Keywords: | C, optimize |
| Organization: | Compilers Central |
| References: | 95-11-076 |
| Date: | Sun, 12 Nov 1995 13:33:14 GMT |
It's simple - don't use goto. Many compilers have extra levels of
optimisation that only kick in when a control construct can be
clearly recognised that are not feasible in general for gotos. Many
compilers won't make any attempt to preserve registers across
arbitrary branches but will preserve them around loops and
conditionals. And as for loop unrolling, invariant hoisting, strength
reduction etc., few compilers will handle these on the raw branch
structure alone - I suspect that the prevalence of structured
programming these days means that such optimisations on raw gotos are
now a province only of old FORTRAN compilers (and even those tended
to benefit from the source being despagged first).
Regards,
----------------------------------------------------------------------
Dave Lloyd Email: Dave@occl-cam.demon.co.uk
Oxford and Cambridge Compilers Ltd Phone: (44) 1223 572074
55 Brampton Rd, Cambridge CB1 3HJ, UK
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.