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