This is the mail archive of the
mailing list for the GCC project.
Re: GSoc-2015: Modular GCC (RFC on refactoring)
- From: Jeff Law <law at redhat dot com>
- To: Mikhail Maltsev <maltsevm at gmail dot com>, gcc mailing list <gcc at gcc dot gnu dot org>
- Date: Tue, 17 Mar 2015 22:31:18 -0600
- Subject: Re: GSoc-2015: Modular GCC (RFC on refactoring)
- Authentication-results: sourceware.org; auth=none
- References: <CAA_ASpVFs7LXS4Pw1Mxo5VCxtEncvYXjYgnULGoRAWnbM3PkYw at mail dot gmail dot com> <54F87A48 dot 6070803 at redhat dot com> <54FA52CD dot 2080003 at gmail dot com> <54FB1C2B dot 7010108 at redhat dot com> <5508F5F3 dot 500 at gmail 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
So, should this be changed somehow?
They may need to be broken out into distinct objects.
Me neither :-) I try real hard to avoid thinking hard about the
gengtype bits. It might need some experimentation..
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?
Dunno. David M. was able to turn the forced_labels EXPR_LIST into a vec
without too much surgery. See:
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?
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.
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 :-)
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
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.