This is the mail archive of the
mailing list for the GCC project.
Re: GSoc-2015: Modular GCC (RFC on refactoring)
- From: Mikhail Maltsev <maltsevm at gmail dot com>
- To: Jeff Law <law at redhat dot com>, gcc mailing list <gcc at gcc dot gnu dot org>
- Date: Wed, 18 Mar 2015 06:50:11 +0300
- 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>
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
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.