Re: [patch] Disable old loop optimizer

[Paul Schlie <schlie at comcast dot net>]

> From: Daniel Jacobowitz <drow@false.org>
>> On Wed, Apr 13, 2005 at 12:22:05PM -0400, Paul Schlie wrote:
>>> Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
>>>> 2) loop reversal (i.e. replacing "for (i = 0; i < n; i++) a[i]=i;" with
>>>>    "for (i = n - 1; i >= 0; i--) a[i]=i;", thus causing us to compare
>>>>    with zero instead of arbitrary bound, and possibly shorten the life
>>>>    range of n).  Should be trivial within linear-transform framework,
>>>>    the major problem is to decide when it is really useful. the major
>>>>    problem is to decide when it is really useful.
>> 
>> It should be considered to be universally useful: as comparing a value
>> against a constant 0 is never more expensive than comparing it against an
>> arbitrary constant, and most typically less expensive because a constant
>> value of 0 is typically both easier to generate if needed as a register
>> value, and/or directly in-lined into a comparison instruction as a small
>> constant when necessary; and/or enables architectures which save implied
>> logical or arithmetic result comparisons against zero in a cc-register,
>> to potentially avoid the necessary of an explicit comparison altogether.
>> 
>> (so it would seem to never be worse, and typically always better.)
> 
> Eh?  Not if you're accessing memory.  For instance, the above example
> may perform considerably worse depending on your cache architecture.
> An example which read from the array, even more so.

Sorry, I'm not sure what you mean:

- if you're referring to cached code; smaller is generally always better,
  therefore compare against 0 is better, as it will mostly likely always
  code.

- if you're referring to the count also being used as an array index into
  memory; I agree that since it affects the memory access sequence it may
  affect cache efficiency, but only if the array is only partially cached,
  as if it's either already fully cached, or not cashed at all, it shouldn't
  have any effect (as you'll either always get a cache hit, or a cache miss
  upon entry to each newly addressed cache line; but understand that upon a
  miss, if the cache controller isn't sensitive to the location of the miss
  within the cache line/block, it may not optimally fill from the most
  optimal end first, thereby increasing the latency to access the requested
  datum; but that would seem to be an inadequacy of the cache controller as
  opposed to anything else, and very target/cache controller specific so not
  sure how or even if it should effect this type of optimization in
  general? Maybe there should be a target switch to enable an incrementing
  or decrementing sequential memory access bias which can influence such
  optimization choices?)