This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Disable old loop optimizer
- From: Daniel Jacobowitz <drow at false dot org>
- To: Paul Schlie <schlie at comcast dot net>
- Cc: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>,Mark Mitchell <mark at codesourcery dot com>, gcc-patches at gcc dot gnu dot org,Daniel Berlin <dberlin at dberlin dot org>, Jeffrey A Law <law at redhat dot com>
- Date: Wed, 13 Apr 2005 13:28:28 -0400
- Subject: Re: [patch] Disable old loop optimizer
- References: <20050413164549.GA30032@nevyn.them.org> <BE82CC6F.9CC0%schlie@comcast.net>
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.
--
Daniel Jacobowitz
CodeSourcery, LLC