|[5 earlier articles]|
|Re: array index checking optimizations? firstname.lastname@example.org (1996-05-01)|
|array index checking optimizations? email@example.com (Dave Lloyd) (1996-05-02)|
|Re: array index checking optimizations? firstname.lastname@example.org (1996-05-03)|
|Re: array index checking optimizations? email@example.com (1996-05-03)|
|Re: array index checking optimizations? firstname.lastname@example.org (1996-05-03)|
|Re: array index checking optimizations? email@example.com (1996-05-03)|
|Re: array index checking optimizations? firstname.lastname@example.org (1996-05-05)|
|Re: array index checking optimizations? Patrick.Cousot@ens.fr (Patrick Cousot) (1996-05-08)|
|From:||email@example.com (Thomas Breuel)|
|Date:||5 May 1996 17:49:53 -0400|
firstname.lastname@example.org (Benjamin Gamsa) writes:
Is it safe to assume that many (most?) compilers will at the least,
reduce checking to loop entry code to verify certain constraints
and/or have multiple versions of a loop depending on run-time values?
Only a few high compilers for high-performance applications will do
that. In fact, compiling multiple versions isn't a win most of the
time, since you usually don't want to pay the memory cost.
Actually, the best way of handling such situations is via on-they-fly
compilation and optimization, when runtime information about hotspots,
types, and bounds is available. Maybe the current flurry of activity
in building JIT compilers for Java will finally make this kind of
Return to the
Search the comp.compilers archives again.