This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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?

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?

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?

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?

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?

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

    Mikhail Maltsev

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]