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)

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:

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 :-)


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