On Wed, Apr 4, 2012 at 5:04 AM, Richard Guenther <richard.guent...@gmail.com> wrote: > On Wed, Apr 4, 2012 at 1:50 PM, Bernd Schmidt <ber...@codesourcery.com> wrote: >> On 04/04/2012 11:06 AM, Richard Guenther wrote: >>> So - I'll veto the switch unless I see 1) and 2). 1) and 2) can be combined >>> 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. Which means targeting mostly isolated sub-systems, > like vec.h (and other various containers), double-int.[ch] (and other various > way of representing and working with constants). Making 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 adapt > 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 = build1 (INDIRECT_REF, some_type, build1 (VIEW_CONVERT_EXPR, some_type, addr)); t = force_gimple_operand (t, &stmts, false, NULL_TREE); gimple_seq_add_seq (&seq, stmts); the_value = make_rename_temp (shadow_type, "__var_name"); g = gimple_build_assign (the_value, t); nm = 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 etc) new_assign_insn = 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 = 0; ORIGINAL BB1 code } // BB2 It can be as simple as the following: basic_block bb0, bb1; gimple_br_inst = gimple::new_cond_br (value:new_cmp_exp (....), bb1, /* taken branch* / &bb2, /* fall through */ &bb2, /* merge point */ &bb0 /* New predecessor */); reset_count = 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.