From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10851 invoked by alias); 5 Jul 2007 18:24:29 -0000 Received: (qmail 10842 invoked by uid 22791); 5 Jul 2007 18:24:28 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 05 Jul 2007 18:24:24 +0000 Received: (qmail 27602 invoked from network); 5 Jul 2007 18:24:22 -0000 Received: from unknown (HELO ?192.168.0.3?) (mitchell@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 Jul 2007 18:24:22 -0000 Message-ID: <468D3743.5090808@codesourcery.com> Date: Thu, 05 Jul 2007 18:34:00 -0000 From: Mark Mitchell User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: bonzini@gnu.org CC: GCC Patches Subject: Re: PR/32004, tree-ssa caused in/out asm constraints to often need reloads References: <468CC82F.2060702@lu.unisi.ch> In-Reply-To: <468CC82F.2060702@lu.unisi.ch> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2007-07/txt/msg00483.txt.bz2 Paolo Bonzini wrote: > The cause and solution of the problem are well explained in the PR trail > and in the comments to the code. > > Bootstrapped/regtested i686-pc-linux-gnu with no new failure and fixing > pr21291.c, ok for 4.2/4.3? I have a couple of minor comments: + if (GET_CODE (pat) == PARALLEL + && GET_CODE (XVECEXP (pat, 0, 0)) == SET + && GET_CODE (SET_SRC (XVECEXP (pat, 0, 0))) == ASM_OPERANDS) + match_asm_constraints_1 (insn, + &XVECEXP (pat, 0, 0), XVECLEN (pat, 0)); + + else if (GET_CODE (pat) == SET + && GET_CODE (SET_SRC (pat)) == ASM_OPERANDS) + match_asm_constraints_1 (insn, &pat, 1); could be more tidily expressed as: if (GET_CODE (pat) == PARALLEL) pat = XVECEXP (pat, 0, 0); if (GET_CODE (pat) == SET && ...) ... Also: + int match; + match = strtoul (constraint, &end, 10); it seems like it would be better just to declare "match" to be "unsigned long". Does your patch handle matching constraints given by "[NAME]"? Other than that, it looks good. -- Mark Mitchell CodeSourcery mark@codesourcery.com (650) 331-3385 x713