From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20318 invoked by alias); 11 Apr 2012 01:01:22 -0000 Received: (qmail 20300 invoked by uid 22791); 11 Apr 2012 01:01:20 -0000 X-SWARE-Spam-Status: No, hits=-5.7 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_TM,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-iy0-f175.google.com (HELO mail-iy0-f175.google.com) (209.85.210.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 11 Apr 2012 01:01:04 +0000 Received: by iaag37 with SMTP id g37so565236iaa.20 for ; Tue, 10 Apr 2012 18:01:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=D8k0BhabA59P1LunOpOybIrs/mnica4wZcNcx96u3ks=; b=RAWj8Q6RxtJe5DrXtrbtPfNj+kvyDQoIdShYFvR3JXsY/ew71qlgxm3usKwRGknTLJ Ybrtf1gQJ9JZQA8RiJmhB5ik4D2cjv9Vu3cQUIdJSCiZCVirTA4HQRSptlPdsnMI3GAZ lSPfa6s1tNMgM59bSoD1qa5DJjbe0uLQ5XH1CTUFr8TzCzzoRA83bZ55ONyqDfrppMVO BdWYdmsZyv+vj7Nfofe2WWfV7PUIeWc9IJMb6hBbyYHc4gT2VxDRJuKtp+WjyiFmAAK2 4rytkWkAlPw4Swo++Ju2HyGutD2YAM+l2vVg8O8FLBXnWGETpHwnMFC5ICzSVJ3uZ1Xj iT0Q== Received: by 10.42.176.8 with SMTP id bc8mr8154132icb.20.1334106063414; Tue, 10 Apr 2012 18:01:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.176.8 with SMTP id bc8mr8154118icb.20.1334106063266; Tue, 10 Apr 2012 18:01:03 -0700 (PDT) Received: by 10.231.210.134 with HTTP; Tue, 10 Apr 2012 18:01:03 -0700 (PDT) In-Reply-To: <20120410084614.GJ6148@sunsite.ms.mff.cuni.cz> References: <4F7B356E.9080003@google.com> <4F7C35A3.3080207@codesourcery.com> <20120410084614.GJ6148@sunsite.ms.mff.cuni.cz> Date: Wed, 11 Apr 2012 01:01:00 -0000 Message-ID: Subject: Re: Switching to C++ by default in 4.8 From: Lawrence Crowl To: Jakub Jelinek Cc: Xinliang David Li , Richard Guenther , Bernd Schmidt , Gabriel Dos Reis , David Edelsohn , Diego Novillo , gcc Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQk6jKDh6tBu99Rno/lCvOrtLToFjLRSbt3JhckOpY9l2dXsP2TlakyqbV7y/hICFPLFtS500rRhyU+SlVYPLQymqm11cMuO/c9t4QuYdIkfEKpBmxeK7oX5mGZVucAFn92naipE X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2012-04/txt/msg00378.txt.bz2 On 4/10/12, Jakub Jelinek wrote: > On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote: > > Class hierarchy is one such feature that is useful. Assuming we > > have two hierarchies for gcc: one for values rooted at ValExp, > > and one for gimple stmts rooted at GimpInst. > > > > 1) For IR browsing, > > *) all the macro accessors can be eliminated -- a big plus > > for debugging; > > Not that clear, if all the macros are replaced by tons of > inline functions, the debugging experience can be actually > significantly worse. Already some the inline functions used > like tree_operand_length used by TREE_OPERAND_LENGTH macro are > extremely annoying from debugging POV. We have options availble to supress those functions in the debugger. Longer term, better debugger support for C++ is the right thing to do. > > *) gcc implementation has lots of hard coded > > TREE_OPERAND (exp, nn) > > > > e.g. > > exp->as_component_ref().get_field() .. > > exp->as_mem_access().get_base() ... > > exp->as_mem_acesss().get_address() > > --> produces the address expression for memory access > > exp->as_mem_access().get_alias_handle () > > gimple_inst->serialize (&fixup_list) > > --> a virtual function overriden by actual instruction types > > that knows its byte code format. > > That silently assumes we want to change basic GIMPLE/tree data > structures to virtual classes, which is a significant change > that has a significant cost as well. I think he was explicit about virtual functions. By virtual classes did you mean virtual bases or classes with virtual functions? I have not seen a need for virtual classes. In any event, much of this work could be done without virtual functions, though that would not be my choice due to the added overhead and complexity. > E.g. all such changed data structures grow by a virtual pointer > field. Those data structures are heavily optimized for memory > footprint. Not to mention it is very questionable if the above > stuff is more readable than what we currently have. A virtual pointer can reduce the size because the dynamic type can encode quite a bit of information that is currently encoded in bitfields. In addition, while the current data structures are densely packed, they are not necessarily information rich. In the PPH branch, we found that near half the pointers we were streaming were null, which says that many of the fields are unused. This information could be shifted to auxilary tables. -- Lawrence Crowl