On Tue, Apr 10, 2012 at 4:14 AM, Richard Guenther
<richard.guent...@gmail.com> wrote:
> On Tue, Apr 10, 2012 at 1:34 AM, Xinliang David Li <davi...@google.com> wrote:
>> 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.
>
> 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?
yes -- I lumped two things together. I care about the high level APIs
more than I care about C++.
>
> And you want to contribute the 10+ man years to consistently(!) transition
> GCC to such API?
>
Transitioning to wrapper APIs above is certainly worth the effort. It
make GCC code lean and mean. Currently there are lots of code
duplication with cut&paste.
> 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.
No need to be sorry. I don't see it happening magically either. If it
needs to be done, it will be carefully designed and incremental.
thanks,
David
>
> 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.
