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.

Reply via email to