Path: utzoo!utgpu!watmath!clyde!att!alberta!myrias!cg From: cg@myrias.UUCP (Chris Gray) Newsgroups: comp.sys.amiga.tech Subject: Re: Dividing by a power of two (Re: Aztec compiler ineffeciencies) Message-ID: <673@myrias.UUCP> Date: 29 Nov 88 22:38:36 GMT References: <8811281919.AA17977@postgres.Berkeley.EDU> Organization: Myrias Research Corporation Lines: 54 In article <8811281919.AA17977@postgres.Berkeley.EDU> dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) writes: An inclusion by John Toebes about Lattice 5.0: >:Actually it is much simpler than that. The Lattice 5.0 compiler generates the >:3 instructions (sometimes 4) inline to perform the division by 2,4, and 8. >:These are the most frequent numbers to occur from analysis of many programs. >:Specifically: >: x/= 2 >: move x,d0 ;unless it was already there >: bpl lab ;skip if positive >: addq #1,d0 ;adjust for rounding >:lab: asr.l #1,d0 ; and do the divide > Lots of discussion by Matt, basically seeming to expression the opinion that a compiler shouldn't bother doing this kind of optimization because a good programmer will do it himself. Also that compilers would get more benefit from other optimizations, such as register tracking. I'll give another compiler-writer's point of view. The optimization discussed above (which is done in Draco 1.2, for all powers of 2) is an easy, and fairly error-free, optimization to do. It is also one that will help out those programmers who don't bother to hand optimize. It is worth noting that the shift may in fact be slower on some machines (image one with a 32 bit array (or whatever they're called) multiplier, and a shift instruction that always requires the shift amount to be loaded into a register). This is precisely the kind of optimization that a compiler SHOULD make. The other kinds of optimizations (register tracking, register colouring, common subexpression elimination, strength reduction, etc. etc.) are often much harder to do. They require lots more code, lots more memory, lots more run-time and end up with lots more bugs. They are HARD to do. Draco 1.2 gets it main code improvements over Draco 1.1 through the following: - peephole optimization - register tracking - user register variables I am STILL finding bugs in the peepholer (the one last night was one which deleted a MOVE to a register variable because the next instruction could use the value directly). So, in short, compiler writers do the simple optimizations because they are simple, and because most people (I guess Matt isn't 'most people' :-) ) expect them to be done. P.S. Draco 1.2 should be going into Beta test soon. If there are any users out there who can commit to a serious Beta test, please let me know. It got delayed when the company I work for sent me to California for a month. -- Chris Gray Myrias Research, Edmonton +1 403 428 1616 {uunet!mnetor,ubc-vision,watmath,vax135}!alberta!myrias!cg