Related articles |
---|
[4 earlier articles] |
Re: array index checking optimizations? Laurent.Guerby@enst-bretagne.fr (Laurent Guerby) (1996-05-01) |
Re: array index checking optimizations? markt@harlequin.co.uk (1996-05-01) |
array index checking optimizations? dave@occl-cam.demon.co.uk (Dave Lloyd) (1996-05-02) |
Re: array index checking optimizations? mad@math.keio.ac.jp (1996-05-03) |
Re: array index checking optimizations? prener@watson.ibm.com (1996-05-03) |
Re: array index checking optimizations? ben@sys.toronto.edu (1996-05-03) |
Re: array index checking optimizations? dlmoore@ix.netcom.com (1996-05-03) |
Re: array index checking optimizations? tmb@best.com (1996-05-05) |
Re: array index checking optimizations? Patrick.Cousot@ens.fr (Patrick Cousot) (1996-05-08) |
From: | dlmoore@ix.netcom.com (David L Moore) |
Newsgroups: | comp.compilers |
Date: | 3 May 1996 23:52:56 -0400 |
Organization: | Netcom |
References: | 96-04-140 |
Keywords: | optimize |
>
> if a'length < b'length then
> last = a'length
> else
> last = b'length
> end if
>
> while i < last do
> if a[i]=b[i] then
> i := i + 1;
> else
> return ord(a[i]) - ord(b[i]);
> end while
Removal of redundant checks is a common optimization. However, I don't
think many compilers will catch this case as there is not a single
definition point for 'last' when you get to the check. One could build
posets, but this is more work whereas the simple cases can be done as
part of value propagation.
The problem with the above code as a candidate for optimization is
that, while it would not be hard to detect this case and optimize it,
it probably doesn't gain you enough to be worth the extra compile time
and development time. The bounds checks in the above loop, for
example, can be hoisted out of the loop, so all the optimization would
save is a couple of compares and traps/jmps, rather than a couple per
iteration.
David Moore
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.