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 01:17:35PM -0400, Paul Schlie wrote:
>> - 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?)
> 
> It sounds like you need to do some research on how modern
> non-microcontroller architectures manage their caches.  Automatic
> prefetching is more sophisticated than this.  I'm confident there are
> at least several architectures that handle sequential-forward memory
> access better than sequential-backward.

Are you suggesting that GCC's optimizations be universally biased toward
the inadequacies of "today's presently modern"/"tomorrow's obsolete" CPU's
inability to more intelligently direct the pre-fetching and filling of their
cache lines/blocks based upon a more intelligently definable or dynamically
determinable access pattern?

(or alternatively acknowledge that it's likely that GCC's optimizations
 could/should be more ideally constructed to enable reasonably simple
 target specific hints to influence their behavior/selection, as different
 generations and/or types of targets will likely continue to benefit from
 different biases based on their architecture and/or implementation
 presumptions?)