Re: Switching to C++ by default in 4.8

[Richard Guenther <richard.guenther@gmail.com>]

On Tue, Apr 10, 2012 at 1:34 AM, Xinliang David Li <davidxl@google.com> wrote:
> On Wed, Apr 4, 2012 at 5:04 AM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>> On Wed, Apr 4, 2012 at 1:50 PM, Bernd Schmidt <bernds@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.

The above is non-readable to me neither.  That we miss a helper
to do the split-the-cfg-here-with-a-conditional-branch-and-bbs-for-true-false
does not mean that such helper has to use whatever fancy C++ interface.
What's wrong with a C helper for the above?  Why is it easier in C++ at all?

And you want to contribute the 10+ man years to consistently(!) transition
GCC to such API?

Sorry, but you cannot magically transform GCC to something more modern.
Thus it will be isolated "leaf" modules that will see conversion.  I don't hold
my breath for even converting the gimple bits, not to even think about trees
(or RTL).

Sorry.

Richard.

>
> 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.