From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,HEADER_SPAM, INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: ff499,32898cca6ca4143e X-Google-Attributes: gidff499,public X-Google-Thread: 103376,32898cca6ca4143e X-Google-Attributes: gid103376,public From: Stefan Monnier Subject: Re: Compiler Optimisation? Date: 1998/12/18 Message-ID: <98-12-034@comp.compilers>#1/1 X-Deja-AN: 423664666 Sender: johnl@iecc.com References: <98-12-010@comp.compilers> <98-12-016@comp.compilers> <98-12-024@comp.compilers> X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com Organization: Compilers Central Keywords: optimize Newsgroups: comp.lang.ada,comp.compilers X-FAQ-and-archives: http://www.iecc.com/compilers Date: 1998-12-18T00:00:00+00:00 List-Id: >>>>> "dewarr" == dewarr writes: > This is misleading. Many compilers do MUCH more extensive > peephole optimization. In particular gcc gets a FAR more > significant improvement from peephole optimization. This often reflects the fact that optimisations interact and that they are often designed based on their interactions. In the SML/NJ example mentioned by someone else, the `contraction' phase is relied upon by many other optimisations (which end up just restructuring the code, which in a first step makes it bigger and slower but exposes further opportunities to the contraction phase). Stefan