On Wed, Aug 28, 2013 at 7:02 PM, Mike Stump wrote:
> On Aug 28, 2013, at 2:34 AM, Richard Biener
> wrote:
>> Huh? Why should wide-int need to be marked GTY at all?!
>
> Can I answer with a question? Why would nb_iter_bound be GTYed?
Because it references a GIMPLE stmt which resides in GC memo
On Aug 28, 2013, at 2:34 AM, Richard Biener wrote:
> Huh? Why should wide-int need to be marked GTY at all?!
Can I answer with a question? Why would nb_iter_bound be GTYed? Why would
dw_val_struct be GTYed? The first makes little sense to me. The second, well,
it is used to generate debug
On Tue, Aug 27, 2013 at 5:06 PM, Mike Stump wrote:
> On Aug 27, 2013, at 4:08 AM, Richard Biener
> wrote:
>>> and converts:
>>> struct GTY(()) cgraph_node
>>> to:
>>> struct GTY((user)) cgraph_node : public symtab_node_base
>
> GTY didn't like single inheritance for me in in wide-int.h. I ext
On Aug 27, 2013, at 4:08 AM, Richard Biener wrote:
>> and converts:
>> struct GTY(()) cgraph_node
>> to:
>> struct GTY((user)) cgraph_node : public symtab_node_base
GTY didn't like single inheritance for me in in wide-int.h. I extended GTY to
support it better. See the wide-int branch, if y
> >>
> >> Also all of the symbol table is reachable from the global symbol_table
> >> dynamic array which is a GC root. So instead of walking ->next/previous
> >> and edges you should have a custom marker for the symbol_table global
> >> which does more efficient marking with loops.
> >
> > Indeed
On Tue, Aug 27, 2013 at 1:40 PM, Jan Hubicka wrote:
>> > + while (x != xlimit)
>> > +{
>> > + /* Code common to all symtab nodes. */
>> > + gt_ggc_m_9tree_node (x->decl);
>> > + gt_ggc_mx_symtab_node_base (x->next);
>> > + gt_ggc_mx_symtab_node_base (x->previous);
>> > +
> > + while (x != xlimit)
> > +{
> > + /* Code common to all symtab nodes. */
> > + gt_ggc_m_9tree_node (x->decl);
> > + gt_ggc_mx_symtab_node_base (x->next);
> > + gt_ggc_mx_symtab_node_base (x->previous);
> > + gt_ggc_mx_symtab_node_base (x->next_sharing_asm_name);
>
On Fri, Aug 16, 2013 at 2:57 AM, David Malcolm wrote:
> This patch is the handwritten part of the conversion of these types
> to C++; it requires the followup patch, which is autogenerated.
>
> It converts:
> struct GTY(()) symtab_node_base
> to:
> class GTY((user)) symtab_node_base
>
> and co
> > On Tue, Aug 20, 2013 at 11:06 PM, Jan Hubicka wrote:
> > >> +/* GTY((user)) hooks for symtab_node_base (and its subclasses).
> > >> + We could use virtual functions for this, but given the presence of
> > >> the
> > >> + "type" field and the trivial size of the class hierarchy, switches
> On Tue, Aug 20, 2013 at 11:06 PM, Jan Hubicka wrote:
> >> +/* GTY((user)) hooks for symtab_node_base (and its subclasses).
> >> + We could use virtual functions for this, but given the presence of the
> >> + "type" field and the trivial size of the class hierarchy, switches are
> >> + perh
On Tue, Aug 20, 2013 at 11:06 PM, Jan Hubicka wrote:
>> +/* GTY((user)) hooks for symtab_node_base (and its subclasses).
>> + We could use virtual functions for this, but given the presence of the
>> + "type" field and the trivial size of the class hierarchy, switches are
>> + perhaps simple
> +/* GTY((user)) hooks for symtab_node_base (and its subclasses).
> + We could use virtual functions for this, but given the presence of the
> + "type" field and the trivial size of the class hierarchy, switches are
> + perhaps simpler and faster. */
Generally I am not really happy about t
This patch is the handwritten part of the conversion of these types
to C++; it requires the followup patch, which is autogenerated.
It converts:
struct GTY(()) symtab_node_base
to:
class GTY((user)) symtab_node_base
and converts:
struct GTY(()) cgraph_node
to:
struct GTY((user)) cgraph_no
13 matches
Mail list logo
