From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5840 invoked by alias); 29 Aug 2008 15:56:36 -0000 Received: (qmail 4221 invoked by uid 48); 29 Aug 2008 15:55:16 -0000 Date: Fri, 29 Aug 2008 15:56:00 -0000 Message-ID: <20080829155516.4220.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/msg02364.txt.bz2 ------- Comment #12 from vmakarov at redhat dot com 2008-08-29 15:55 ------- Here is the analysis of regressions on pr36222 and pr36246. PR36222 contains the following code: p64:V4SI=vec_concat (p66:V2SI, p65:V2SI) dead p66 and p65 xmm0:V2DI=subreg:V2DI (p64:V4SI) IRA allocates p65, p66, and p64 in this order. p65 gets xmm0, p66 gets xmm1, and p64 gets xmm0. Reload generates additional move insn because p66 and p64 should be the same operand according to the 1st insn constraints. IRA uses copies to propagate preferences. p66 and pc64, p66 and p64 connected by copies with same frequencies as dying pseudos. IRA did not create copy connecting p66 and p64 as operands should be in the same register according to the insn constraints because IRA does not create copies for allocnos with different modes. Preference of xmm0 was not propagated to p64 because IRA does not create copies for subregs. Another pitfall of IRA, it propagates preferences only from allocnos *directly* connected by copies. The patch solving the problem will be sent soon. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37243