From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29744 invoked by alias); 30 Aug 2008 18:53:37 -0000 Received: (qmail 29247 invoked by uid 48); 30 Aug 2008 18:52:17 -0000 Date: Sat, 30 Aug 2008 18:53:00 -0000 Message-ID: <20080830185217.29246.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "vmakarov at redhat 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: 2008-08/txt/msg02447.txt.bz2 ------- Comment #16 from vmakarov at redhat dot com 2008-08-30 18:52 ------- This is an analysis of the SPEC2006 degradation. First of all of thanks for reducing the test. I really appreciate this. Finding it in spec20006 would be very time consuming for me. The problem looks following 1. pseudo 80 in the 1st loop gets hard register #2, pseudo 153 in the same loop gets hard register #5. 2. Reload spills pseudo 80 and than assigns it to hard register #5 through IRA. Although p80 and p153 in the 1st loop really conflict. It happens because of wrong flattening regional IR into plain IR done for reload. IR flattening is wrong because ira-emit.c (see end of function ira-emit.c::change_loop) does not rename disjoint live ranges of p153 in the 1st loop and in another top-level loop. Again it happens because p153 in the 1st loop is not in bitmap mentioned_allocnos. p153 is not mentioned in the 1st loop (only in its subloops) but lives through BBs of the 1st loop. The patch solving the problem will be sent soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37243