From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13780 invoked by alias); 6 Nov 2007 18:20:54 -0000 Received: (qmail 13767 invoked by uid 22791); 6 Nov 2007 18:20:53 -0000 X-Spam-Check-By: sourceware.org Received: from outbound-sin.frontbridge.com (HELO outbound5-sin-R.bigfish.com) (207.46.51.80) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 06 Nov 2007 18:20:50 +0000 Received: from outbound5-sin.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound5-sin-R.bigfish.com (Postfix) with ESMTP id 8E7AE1568E3B; Tue, 6 Nov 2007 18:19:23 +0000 (UTC) Received: from mail9-sin-R.bigfish.com (unknown [10.3.40.3]) by outbound5-sin.bigfish.com (Postfix) with ESMTP id 6948A19E005A; Tue, 6 Nov 2007 18:19:23 +0000 (UTC) Received: from mail9-sin (localhost.localdomain [127.0.0.1]) by mail9-sin-R.bigfish.com (Postfix) with ESMTP id 0264839010C; Tue, 6 Nov 2007 18:19:05 +0000 (UTC) X-BigFish: VP X-MS-Exchange-Organization-Antispam-Report: OrigIP: 163.181.251.22;Service: EHS Received: by mail9-sin (MessageSwitch) id 1194373143782269_19305; Tue, 6 Nov 2007 18:19:03 +0000 (UCT) Received: from ausb3extmailp02.amd.com (rebel3.amd.com [163.181.251.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail9-sin.bigfish.com (Postfix) with ESMTP id BD6BD19A8058; Tue, 6 Nov 2007 18:19:02 +0000 (UTC) Received: from SAUSGW02.amd.com (sausgw02.amd.com [163.181.250.22]) by ausb3extmailp02.amd.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id lA6IIw0I011694; Tue, 6 Nov 2007 12:19:18 -0600 Received: from [163.181.22.101] by SAUSGW01.amd.com with ESMTP (AMD SMTP Relay (Email Firewall v6.3.1)); Tue, 06 Nov 2007 12:19:14 -0600 X-Server-Uuid: D6C75999-9DAF-4D89-B9AC-C25E3A0BB76A Received: from sausexmb2.amd.com ([163.181.3.157]) by sausexbh1.amd.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 6 Nov 2007 12:19:14 -0600 Received: from mmeissner-gold.amd.com ([165.204.57.57]) by sausexmb2.amd.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Nov 2007 12:18:39 -0600 Received: from mmeissner-gold.amd.com (localhost [127.0.0.1]) by mmeissner-gold.amd.com (8.13.8/8.13.8) with ESMTP id lA6IIc4Z032757; Tue, 6 Nov 2007 13:18:38 -0500 Received: (from mmeissne@localhost) by mmeissner-gold.amd.com ( 8.13.8/8.13.8/Submit) id lA6IIcQD032756; Tue, 6 Nov 2007 13:18:38 -0500 Date: Tue, 06 Nov 2007 18:20:00 -0000 From: "Michael Meissner" To: "Andreas Krebbel" cc: gcc-patches@gcc.gnu.org Subject: Re: [PING] Target hook for rewriting inline asm constraints Message-ID: <20071106181838.GA31748@mmeissner-gold.amd.com> Mail-Followup-To: Michael Meissner , Andreas Krebbel , gcc-patches@gcc.gnu.org References: <20071030115424.GA6864@homer.boeblingen.de.ibm.com> MIME-Version: 1.0 In-Reply-To: <20071030115424.GA6864@homer.boeblingen.de.ibm.com> User-Agent: Mutt/1.4.2.3i X-WSS-ID: 6B2E6FA824S1586789-01-01 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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-11/txt/msg00275.txt.bz2 On Tue, Oct 30, 2007 at 12:54:24PM +0100, Andreas Krebbel wrote: > Hello, > > could a C front end and/or middle end maintainer please have a look at > this one: > > http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01407.html I'm catching up on my backlog. Here are the nit-picky comments about the change: First, fixed size string arrays (result and tmp in c_parser_asm_operands) is not a good idea. Second, using repeated strlen calls to grow the string is also not a good idea (in c_parser_asm_operand). Third the local variables for c_parser_asm_operand should be moved into the outer scope. Fourth, you added the include file tm_p.h to the includes of c-parser.c, but I did not see a corresponding modification to Makefile.in for this dependency. Now, getting on the broader scope issues about the patch, I can sympathize with the desire, but I think this is really opening up a can of worms if we let the back end rewrite asm constraints like this. I'm also not sure I understand what the exact problem is. I would imagine if you have address modes that are allowed in some cases, but not others, this is better expressed in GO_IF_MODE_DEPENDENT_ADDRESS instead of GO_IF_LEGITIMATE_ADDRESS. -- Michael Meissner, AMD 90 Central Street, MS 83-29, Boxborough, MA, 01719, USA michael.meissner@amd.com