From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11532 invoked by alias); 25 Feb 2009 17:54:14 -0000 Received: (qmail 11462 invoked by uid 48); 25 Feb 2009 17:53:55 -0000 Date: Wed, 25 Feb 2009 17:54:00 -0000 Message-ID: <20090225175355.11461.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/31862] Loop IM and other optimizations harmful for -fopenmp In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "davids at webmaster dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-02/txt/msg02192.txt.bz2 ------- Comment #20 from davids at webmaster dot com 2009-02-25 17:53 ------- I don't like this either: tmp = var; modified = false; for (i = 0; i < 100; i++) { if (i > x) tmp = i, modified = true; } if (modified) var = tmp; This can be a pessimization as well. If 'modified' is almost always false, the 'tmp = var;' can force a cache unshare for no reason. If this code is not performance critical, the optimization is pointless. If it is, the pessimization can be significant. IMO, these kinds of optimizations are not worth doing. Almost any optimization that can introduce an additional memory access risks a net performance loss in some use cases. The compiler cannot determine the use case by static code inspection. Now, in this case, the 'tmp = var;' is obviously superfluous, you can just eliminate it, so this isn't a good example of what I'm talking about. But in general, an optimization should not *add* a memory operation the code did not request unless you can show that it will always remove at least one operation of comparable cost. Otherwise it can be a net performance loss all the time in some use cases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31862