On Wed, Apr 4, 2012 at 5:04 AM, Richard Guenther
<[email protected]> wrote:
> On Wed, Apr 4, 2012 at 1:50 PM, Bernd Schmidt <[email protected]> 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.
