Re: programmer optimizations?

davidm@Rational.COM (David Moore)
Sat, 31 Dec 1994 20:06:31 GMT

          From comp.compilers

Related articles
programmer optimizations? (Afsal C. Majeed) (1994-12-28)
Re: programmer optimizations? davidm@Rational.COM (1994-12-31)
Re: programmer optimizations? (1995-01-01)
Re: programmer optimizations? (1995-01-02)
Re: programmer optimizations? jbuck@Synopsys.COM (1995-01-02)
Re: programmer optimizations? (Erkki Ruohtula) (1995-01-11)
Re: programmer optimizations? (1995-01-05)
Re: programmer optimizations? (1995-01-05)
[12 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: davidm@Rational.COM (David Moore)
Keywords: optimize
Organization: Rational Software Corporation
References: 94-12-145
Date: Sat, 31 Dec 1994 20:06:31 GMT

"Afsal C. Majeed" <> 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.

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.