From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7675 invoked by alias); 15 May 2009 02:16:28 -0000 Received: (qmail 7553 invoked by uid 48); 15 May 2009 02:16:08 -0000 Date: Fri, 15 May 2009 02:16:00 -0000 Message-ID: <20090515021608.7552.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/39976] [4.5 Regression] Big sixtrack degradation on powerpc 32/64 after revision r146817 In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "luisgpm at linux dot vnet dot ibm 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-05/txt/msg01287.txt.bz2 ------- Comment #17 from luisgpm at linux dot vnet dot ibm dot com 2009-05-15 02:16 ------- Actually, 64-bit is affected too, but not with the "power6x" tuning i was using. With "-mcpu=power6" i can reproduce the problem. The problem seems to be a couple load instructions that are being pushed up from a different basic block, and this results in a Load-hit-store hazard, since we've pushed the load too close to a store to the same address. I'm not sure this is a direct consequence of changes in the gimple code. Would you know Matz? I'll continue digging... Luis -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39976