Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!whuxl!whuxlm!akgua!gatech!seismo!lll-crg!lll-lcc!qantel!hplabs!tektronix!tekcrl!tekchips!stevev From: stevev@tekchips.UUCP Newsgroups: net.arch Subject: Re: Addressing modes Message-ID: <120@tekchips.UUCP> Date: Wed, 12-Mar-86 13:24:30 EST Article-I.D.: tekchips.120 Posted: Wed Mar 12 13:24:30 1986 Date-Received: Mon, 17-Mar-86 03:26:37 EST References: <946@garfield.UUCP> <1417@sdcsvax.UUCP> Organization: Tektronix, Beaverton OR Lines: 28 > You miss my point. The optimisations described (in this case common > expression detection) are possible *regardless* of the target > machine's architecture. Any good compiler should try to optimise > code like this. However, once these "source level" and flow analysis > optimisations are finished, there should be only one reasonable way > of generating the machine code. Otherwise, the poor compiler writer > has to do another set of optimisation analyses, all because of the > target machine's instruction set. Even though an the correctness of an optimization is machine-independent, its effect on the quality of code is very machine-dependent. The selection of the ``best'' source-level optimizations will differ from machine to machine, even for RISCs. Consider common-subexpression elimination. Sure, you can perform the optimization at source level, but for some machines, it might be cheaper to redo the computation rather than to save the result because saving the result requires a register, which could register allocation poorer; in some cases, reperforming the computation could even be free on RISC machines if it can be done in an instruction that would otherwise be a delayed-branch-induced NOP. The point is that architectural attributes such as *the number of available registers* and *delayed branching* can effect which optimizations you should (should not) do at the source-level. Steve Vegdahl Computer Research Lab. Tektronix, Inc. Beaverton, Oregon