From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28516 invoked by alias); 2 Jul 2005 01:49:26 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 28481 invoked by uid 22791); 2 Jul 2005 01:49:20 -0000 Received: from w098.z064220152.sjc-ca.dsl.cnc.net (HELO bluesmobile.specifixinc.com) (64.220.152.98) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sat, 02 Jul 2005 01:49:20 +0000 Received: from specifixinc.com (bluesmobile.corp.specifix.com [192.168.1.2]) by bluesmobile.specifixinc.com (Postfix) with ESMTP id EB8FC16A65; Fri, 1 Jul 2005 18:49:18 -0700 (PDT) Message-ID: <42C5F29E.6000004@specifixinc.com> Date: Sat, 02 Jul 2005 01:49:00 -0000 From: James E Wilson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.6) Gecko/20040114 MIME-Version: 1.0 To: Martin Koegler Cc: gcc@gcc.gnu.org Subject: Re: named address spaces (update) References: <20050629084740.GA8315@ahab.auto.tuwien.ac.at> In-Reply-To: <20050629084740.GA8315@ahab.auto.tuwien.ac.at> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-07/txt/msg00057.txt.bz2 Martin Koegler wrote: > I continued to work on the support for named address spaces in GCC. This does look like a good start. An possible issue is the effect on gcc memory usage and compile time. I see you increased the size of MEM rtl which will increase memory usage. Also, there seem to be a lot of hooks in commonly called functions which may slow down gcc. Most users won't be happy if gcc gets slower in order to implement an obscure feature that most don't need. It would be useful to measure the effect on compile time performance, and try to reduce it if it is too much. It would be helpful if you used -p when running diff. That includes function names in the output, which makes the patch easier to read. Also, a ChangeLog entry would help. In previous threads, Joseph Myers pointed you at a formal proposal to extend the ISO C language with a similar feature. Have you looked at this? If we are adding this feature, it would be best if we followed the standard, instead of inventing our own incompatible extensions. I see lots of places where you haven't followed the GNU coding conventions. This will matter if you are serious about getting this patch into the FSF tree. Comments need to start with a capital letter and end with a period. Functions must have a comment before them that explains what they do, and what their arguments are. Spaces before open parentheses. Spaces before and after operators like = and !=. namespace means something different in C++. I don't think it is wise to reuse it here. addressspace or addrspace makes more sense. It isn't clear why you want both decl and type attributes. If we are doing this right, it seems that it should just be a type attribute (type qualifier?), and then for decls you can get the info from their type. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com