From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1486 invoked by alias); 4 Sep 2008 19:46:41 -0000 Received: (qmail 1040 invoked by uid 48); 4 Sep 2008 19:45:20 -0000 Date: Thu, 04 Sep 2008 19:46:00 -0000 Message-ID: <20080904194520.1039.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug middle-end/37364] [4.4 Regression] IRA generates inefficient code In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "hjl dot tools at gmail 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-09/txt/msg00574.txt.bz2 ------- Comment #7 from hjl dot tools at gmail dot com 2008-09-04 19:45 ------- (In reply to comment #6) > First of all, I've check the generated code on Core2 and I found it is not > slower than using movd. I think MMX may be slow anyway. > The reason for this is in insn > > (insn:HI 14 8 20 2 > /home/cygnus/vmakarov/build/ira-merge-branch/gcc/gcc/testsuite/gcc.target/i386/pr34256.c:12 > (set (reg/i:DI 0 ax) > (subreg:DI (reg:V2SI 61) 0)) 89 {*movdi_1_rex64} (expr_list:REG_DEAD > (reg:V2SI 61) > (nil))) > > which has the following description > > (define_insn "*movdi_1_rex64" > [(set (match_operand:DI 0 "nonimmediate_operand" > "=r,r ,r,m ,!m,*y,*y,?r ,m ,?*Ym,?*y,*x,*x,?r ,m,?*Yi,*x,?*x,?*Ym") > (match_operand:DI 1 "general_operand" > "Z ,rem,i,re,n ,C ,*y,*Ym,*y,r ,m ,C ,*x,*Yi,*x,r ,m ,*Ym,*x"))] > "TARGET_64BIT && !(MEM_P (operands[0]) && MEM_P (operands[1]))" > > Please, look at the 8th alternatives ?r *Ym which corresponds to GENERAL_REGS > MMX_REGS. ? makes the alternative expensive. * is even worse because it > excludes the alternative from register cost calculation. You are right. > The old register allocator would behave the same way if regmove did not > coalesced r61 with another pseudo and the result pseudo had not MMX cost > cheaper than memory. > > There are several ways to fix the problem: > > o ignore * and ? in the cost calculation > o fix the pattern > o run regmove as the old RA > o make failure expected > > So I'd prefer the last solution. I agree, given that it only affects MMX. Uros, what do you think? Should we mark gcc.target/i386/pr34256.c as XFAIL? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37364