On Wed, Mar 18, 2015 at 06:50:11AM +0300, 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?
if by "the list of insns" you mean the chain for a set of rtx_insn_list's then yes. > 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? given std::forward_list isn't available in c++98 I expect you'll write your own version of it. It seems pretty reasonable to me function.h would depend on the hypothetical header containing that list template, and presumably more stuff than just rtx_insn_list's could be made to use it. > 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? dealing with ggc is... complex :( To start its probably simplest though pretty sub optimal to keep the nodes in gc memory. > 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? One of the few good things about ggc is that we can modify it to suite our needs. However the tricky bit is PCH writing. > 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? maybe, though ggc does have finalizers now, so its possible we could move all the lists out of gc memory. > > 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 can just look by greping for as_a / dyn_cast. Trev > > -- > Regards, > Mikhail Maltsev
