Re: GSoc-2015: Modular GCC (RFC on refactoring)

[Jeff Law <law at redhat dot com>]

On 03/17/2015 09:50 PM, Mikhail Maltsev wrote:
> 07.03.2015 18:41, Jeff Law wrote:
> > One potentially easy project there would be to take David Malcolm's work to
> > turn the RTL EXPR & INSN lists into standard C++ forward lists.
>
> Started working on this. I need to understand, if I'm moving in the
> right direction (i.e. whether my understanding of what needs to be done
> is correct). I got some basic grasp of GCC internals, but the code base
> is huge, and I still have a lot of questions :(
>
> 1. The list of INSNs is non-intrusive, i.e. nodes of such list no longer
> need to be subclasses of struct rtx_def and/or members of rtunion, right?
Right, they should be rtx_insn *.

> 2. Lists, list nodes and list iterators should be objects of distinct
> types. In this case, header file function.h gets additional dependency,
> because struct rtldata contains insn/expr lists as members; currently
> they are pointers, so a forward declaration is sufficient. A possible
> workaround is to create an opaque type like it's done with struct
> initial_value_struct (at a cost of one additional level of indirection).
> Which is better?
I'd probably stick with a forward declaration.


> 3. List nodes can be allocated in a separate pool rather than
> garbage-collected memory. Not sure, what should be done with reg_notes.
> They use insn lists, but it seems to me that insn lists in reg_notes are
> a different concept than, say, lists used by scheduler and register
> allocator), according to rtlanal.c:
>        /* These types of register notes use an INSN_LIST rather than an
> 	 EXPR_LIST, so that copying is done right and dumps look
> 	 better.  */
> So, should this be changed somehow?
They may need to be broken out into distinct objects.


> 4. I don't understand precisely, how all this stuff will interact with
> garbage collector. Is it possible, for example, to register an insn_list
> object as a GC root with custom marking function in it's constructor,
> and remove it, when the list is destroyed?
Me neither :-)  I try real hard to avoid thinking hard about the 
gengtype bits.  It might need some experimentation..

> 5. EXPR lists seem to be harder to separate from other RTL objects,
> because they are owned by GC-managed RTL objects. Maybe we need to have
> both pool-allocated and GC-managed lists?
Dunno.  David M. was able to turn the forced_labels EXPR_LIST into a vec 
without too much surgery.  See:

https://gcc.gnu.org/ml/gcc-patches/2014-08/msg00825.html

I'm not a big fan of keeping the FOR_EACH_blah style iterator and would 
prefer to use real C++ iterators.  But it ought to give you some ideas 
about how to start breaking these things out.

> > One that's harder would be pushing the rtx_insn * class further.  Basically
> > most of the places where we have a as-a cast between rtx_insn * and an
> > rtx is a good candidate for removal and further propagation of rtx_insn
> > * types.
>
> I'll try to figure out, if it's possible to automate this. Perhaps, by
> writing a plugin, which traverses C++ AST (in PLUGIN_PRE_GENERICIZE) and
> searches for such casts.
You probably should talk do David about this kind of approach.  It fits 
in with his style of work.  I'm much more of a remove the as-a cast, 
then beat the code into submission :-)

Jeff
>