From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31247 invoked by alias); 9 Apr 2012 23:34:52 -0000 Received: (qmail 31233 invoked by uid 22791); 9 Apr 2012 23:34:50 -0000 X-SWARE-Spam-Status: No, hits=-5.5 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-lpp01m010-f47.google.com (HELO mail-lpp01m010-f47.google.com) (209.85.215.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 09 Apr 2012 23:34:35 +0000 Received: by lagw12 with SMTP id w12so3908688lag.20 for ; Mon, 09 Apr 2012 16:34:33 -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:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=N2xC4VfX7JheqJ0BM945Z//6PDM0VXUNBHdwbbrMVa4=; b=MW3Ah/26CtfVg+FL4v5X9pygtbkzPx04CZMKQ1Kcz+I0o0IKw99nK5MSnlWxsVXBas Dytuh2YZx6fRJUijwR2MiMAx19CKR6PB+xMZAiJ+98IEURVjb7PHq3tfUi19AsKRnwUO hbhbAaAsSEMvxRZp6Ya1qf7PI6lgKRIQQk7lmcg8ciSDs/kywWqDPxSJeIUtP0dqqw56 foQOXTzh7lAOSS548Vhvkhb373eH6gBaN4yjiSB9u4CoeqoAS6bX/fG88BsF5WsCCUB0 EDlQEBw2snLfAsjiCRJLoweWeVKfFc1Zep6JYZoGV8154i8IrFjMG7Glf29h/XY3DOC/ +CaQ== Received: by 10.112.11.6 with SMTP id m6mr444192lbb.24.1334014473251; Mon, 09 Apr 2012 16:34:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.11.6 with SMTP id m6mr444178lbb.24.1334014473073; Mon, 09 Apr 2012 16:34:33 -0700 (PDT) Received: by 10.152.4.233 with HTTP; Mon, 9 Apr 2012 16:34:32 -0700 (PDT) In-Reply-To: References: <4F7B356E.9080003@google.com> <4F7C35A3.3080207@codesourcery.com> Date: Mon, 09 Apr 2012 23:34:00 -0000 Message-ID: Subject: Re: Switching to C++ by default in 4.8 From: Xinliang David Li To: Richard Guenther Cc: Bernd Schmidt , Gabriel Dos Reis , David Edelsohn , Diego Novillo , gcc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQkn/MKimEVrhCpnS+dn5awV0wvJA9Fze2lE3nt7Lp//EVZHlpEOW8K+O0L5ovFkbuWjwswIZo/ZtrtQLT3cH9YJkWJU3+MzGR6Jxytb0s3NY8Rhi6IZY3cgiLH0j/GzDDHwcQDB 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/msg00296.txt.bz2 On Wed, Apr 4, 2012 at 5:04 AM, Richard Guenther wrote: > On Wed, Apr 4, 2012 at 1:50 PM, Bernd Schmidt w= rote: >> On 04/04/2012 11:06 AM, Richard Guenther wrote: >>> So - I'll veto the switch unless I see 1) and 2). =A01) and 2) can be c= ombined >>> by transitioning vec.h to a C++ template class, with proper GC support. >>> (not sure that I can veto anything - heh) >> >> I don't think I can veto anything, but I'll go on the record again >> saying that I don't think this entire plan is a good idea. Write a new >> project in C++? Absolutely. Convert a large existing one to a different >> language? A huge waste of time that will distract us for years from >> actual user-visible changes. > > I agree for the idea of converting all of GCC to C++ (whatever that means= ). > I disagree for the part making the internal infrastructure easier to use, > understand and maintain. =A0Which means targeting mostly isolated sub-sys= tems, > like vec.h (and other various containers), double-int.[ch] (and other var= ious > way of representing and working with constants). =A0Making tree or gimple= a > C++ class with inheritance and whatever is indeed a huge waste of time > and existing developer ressources (that, if only because they have to ada= pt > and maintain two completely different code-bases over some time). > > I expect the GCC core to maintain written in C, compiled by C++. GCC's current C programming APIs (both browsing APIs and creator/factory APIs) are somewhat primitive and too low level. I expect switching to C++ can significantly make GCC more modern looking. It can greatly improve readability and productivity (for simplifying transformation and instrumentation development). C++ features should not be be abused (e.g., MI, VI etc), but we should not miss on basic C++ features. 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; *) 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. For experienced GCC developers, current APIs won't a problem at all -- but it does become a big minus for newbies and in the long run will hurt gcc community. 2) IR manipulation APIs -- the problem seems more serious. It seems GCC prefers low level APIs so that incremental update of derived data (control flow, SSA) can be easier -- but that does not have to be the case -- high level APIs can hide most of the update from the programmer. Example: Create a a simple assignment instruction from a load (this example comes from Asan implementation in gcc by Kostya) t =3D build1 (INDIRECT_REF, some_type, =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0build1 (VIEW_CONVERT_EXPR, some_typ= e, addr)); =A0t =3D force_gimple_operand (t, &stmts, false, NULL_TREE); =A0gimple_seq_add_seq (&seq, stmts); =A0the_value =3D make_rename_temp (shadow_type, "__var_name"); =A0g =3D gimple_build_assign (the_value, t); nm =3D make_ssa_name (the_value, g); gimple_assign_set_lhs (g, nm); This can be as simple as (by hiding the gimplification, ssa name creation e= tc) new_assign_insn =3D gimple::new_load_insn (INDIRECT_REF, some_type, addr= _exp); new_assign_insn->get_lhs()->as_ssa_name()->get_val_decl()->setname("..."= ); The creator interface can also take a form that accepts the addr_insn that produces the address. Another example: Instrument a BB1 so that it is guarded: if (counts > sampling_rate) // BB0 { counts =3D 0; ORIGINAL BB1 code } // BB2 It can be as simple as the following: basic_block bb0, bb1; gimple_br_inst =3D gimple::new_cond_br (value:new_cmp_exp (....), bb1, /* taken branch* / &bb2, /* fall through */ &bb2, /* merge point */ &bb0 /* New predecessor */); reset_count =3D gimple:new_store_insn (..., bb1, insert_before); If the current APIs are used to do the coding, it will take how X times more API calls which is non-readable for human beings. thanks, David > >> I also find debugging C++ in gdb somewhat more annoying than debugging >> plain C, and at the moment I always go back to a stage1 compiler. > > Indeed - I'd be worried if my debugging efficiency decreases by more than= 5%. > > Richard.