Re: programmer optimizations?

hbaker@netcom.com (Henry Baker)
Wed, 1 Feb 1995 03:58:00 GMT

          From comp.compilers

Related articles
[10 earlier articles]
Re: programmer optimizations? synaptx!carambole!daveg@uunet.uu.net (Dave Gillespie) (1995-01-11)
Re: programmer optimizations? det@sw.stratus.com (David Toland) (1995-01-11)
Re: programmer optimizations? cdg@nullstone.com (1995-01-23)
Re: programmer optimizations? hbaker@netcom.com (1995-01-27)
Re: programmer optimizations? cdg@nullstone.com (1995-01-31)
Re: programmer optimizations? c1veeru@WATSON.IBM.COM (Virendra K. Mehta) (1995-02-02)
Re: programmer optimizations? hbaker@netcom.com (1995-02-01)
Re: programmer optimizations? bill@amber.ssd.csd.harris.com (1995-02-01)
Re: programmer optimizations? gnb@bby.com.au (1995-02-02)
Re: programmer optimizations? rfg@rahul.net (Ronald F. Guilmette) (1995-02-04)
| List of all articles for this month |

Newsgroups: comp.compilers
From: hbaker@netcom.com (Henry Baker)
Keywords: optimize
Organization: nil
References: 95-01-083 95-01-114
Date: Wed, 1 Feb 1995 03:58:00 GMT

hbaker@netcom.com (Henry Baker) wrote:
> Before everyone gets too upset here, it is quite difficult--in
> general--for a compiler to keep track of whether a number is positive,
> negative or zero.
> When it comes to range information in which one or both ends of the range
> are a run-time variable, the complexity of static analysis skyrockets.


cdg@nullstone.com (Christopher Glaeser) wrote:
> I was referring to the negative constant divisor, not variable dividend.
> For example, consider the following expression.
>
> foo / -8
>
> All the power-of-two optimizations I listed in the previous message are
> easy to implement (e.g. do not require flow information).
>
> In early releases of Nullstone, we only tested a few combinations of
> power-of-two optimizations, thinking that if a compiler optimized
> (foo / (1 << 3)), that it probably optimized (foo / (1 << 15)).
> Our analysis of twenty compilers on a variety of platforms revealed
> that very few compilers generate efficient code for all combinations
> of positive/negative signed/unsigned power-of-two multiply/divide/mod.


Well, part of the reason is the brain-damaged hardware that doesn't
provide both 'trunc' and 'floor' forms of division. 'trunc' division
is Fortran 'round' towards zero division, while 'floor' division is
APL/Knuth 'round' towards -infinity division. Then there are brain-
damaged languages -- e.g., C -- that don't provide for a rounding
float-to-integer conversion.
(see ftp://ftp.netcom.com/pub/hb/hbaker/AB-mod-N.html (also .ps.Z) for
an example of where C falls down.)


It's looooong past time for some inter-language standards committee to nail
down these issues wrt to division and integer conversion. I highly recommend
the goals (though not necessarily the final results) of the Common Lisp
language, which provides all four operations: floor, ceiling, truncate, and
round.


(see also ftp://ftp.netcom.com/pub/hb/hbaker/Gaussian.html (also .ps.Z)
for some uses of some of these.)
--


Post a followup to this message

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