|[7 earlier articles]|
|Re: programmer optimizations? firstname.lastname@example.org (1995-01-05)|
|Re: programmer optimizations? email@example.com (1995-01-12)|
|Re: programmer optimizations? firstname.lastname@example.org (Stefan Monnier) (1995-01-21)|
|Re: programmer optimizations? email@example.com (Dave Gillespie) (1995-01-11)|
|Re: programmer optimizations? firstname.lastname@example.org (David Toland) (1995-01-11)|
|Re: programmer optimizations? email@example.com (1995-01-23)|
|Re: programmer optimizations? firstname.lastname@example.org (1995-01-27)|
|Re: programmer optimizations? email@example.com (1995-01-31)|
|Re: programmer optimizations? c1veeru@WATSON.IBM.COM (Virendra K. Mehta) (1995-02-02)|
|Re: programmer optimizations? firstname.lastname@example.org (1995-02-01)|
|Re: programmer optimizations? email@example.com (1995-02-01)|
|Re: programmer optimizations? firstname.lastname@example.org (1995-02-02)|
|Re: programmer optimizations? email@example.com (Ronald F. Guilmette) (1995-02-04)|
|From:||firstname.lastname@example.org (Henry Baker)|
|Date:||Fri, 27 Jan 1995 03:54:07 GMT|
email@example.com (Christopher Glaeser) wrote:
> > > replacing (n / 4)
> > > by (n >> 2)
> > Unfortunately it seems you cannot always trust the compiler writers
> > to do the right thing here.
> We have evaluated approximately twenty compilers on a variety of
> architectures using Nullstone, an automated compiler performance analysis
> tool, and have made similar observations. Replacing power of 2 multiply,
> divide, and mod with shift or shift/add/sub sequences can improve
> performance on many machines, and is a relatively easy optimization,
> yet many compilers generate less-than-optimal code for at least some
> power of 2 expressions.
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. The Ada language goes to a lot of trouble to allow the
user to provide precise range information, but then most compilers proceed
to spit back into your face if you actually give this information to them
(i.e., they then provide _worse_ code). Ditto for Common Lisp and its
compilers, which allows the programmer to specify more-or-less precise
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.
This is why it is unlikely that compilers will be providing ML-style type
inference for array bounds any time soon.
Some references are at URL's:
ftp://ftp.netcom.com/pub/hb/hbaker/TInference.html (or .ps.Z) and
ftp://ftp.netcom.com/pub/hb/hbaker/Subtypep.html (or .ps.Z).
Return to the
Search the comp.compilers archives again.