|programmer optimizations? firstname.lastname@example.org (Afsal C. Majeed) (1994-12-28)|
|Re: programmer optimizations? davidm@Rational.COM (1994-12-31)|
|Re: programmer optimizations? email@example.com.OZ.AU (1995-01-01)|
|Re: programmer optimizations? firstname.lastname@example.org (1995-01-02)|
|Re: programmer optimizations? jbuck@Synopsys.COM (1995-01-02)|
|Re: programmer optimizations? email@example.com (Erkki Ruohtula) (1995-01-11)|
|Re: programmer optimizations? firstname.lastname@example.org.OZ.AU (1995-01-05)|
|Re: programmer optimizations? email@example.com (1995-01-05)|
|[12 later articles]|
|From:||davidm@Rational.COM (David Moore)|
|Organization:||Rational Software Corporation|
|Date:||Sat, 31 Dec 1994 20:06:31 GMT|
"Afsal C. Majeed" <firstname.lastname@example.org> writes:
>We are having small debate here as to the use of some of the
>code optimizations by the programmer himself.
> replacing (n / 4)
> by (n >> 2)
As John remarked, this only works if n>=0. The real question is
how much work does a given compiler do to determine n>=0. If
n is declared unsigned, almost every compiler will make this
reduction of strength. Any loop containing a divide is doomed
to run slowly, so optimizer writers are always keen to eliminate
> replacing if ((i < 0) || (j < 0) || (k < 0))
> by if ((i | j | k) < 0)
>as you can well imagine, the list is endless
Some compilers will do this too. Jumps are bad on most Risc platforms, so
compilers will go to a lot of trouble to replace jumps with shifts and
masks. This is a particularly simple case.
It is a bad thing to do explicitly because you kill the potential
parallelism in the first form.
A multi issue machine could potentially do all three compare and jumps in
form 1 in a single cycle while the second form requires at least 3 cycles.
It is much more likely that a compiler will transform the separate tests
into an efficient form than it will break open the tricky form into
separate tests in order to increase the issue rate simply because the
second form is more tricky and therefore probably does not occur often
enough to be worth looking for.
Return to the
Search the comp.compilers archives again.