> However, did you check that the atomic qualifier is correctly written &
> re-read in the state (I believe you did, otherwise it probably won't
> work). This is needed for plugins using it, or using atomic qualified
> fields of existing (or future) structures.

Yes.  String options are written as they are, no particular changes are
needed. ;-)

I'd like to show you a testcase, but, as you discuss in your other email, we 
can't
really write GTY testcases at this stage.  So here is a walked tour of how to 
test
the new atomic option --

 * apply the GTY ((atomic)) patch (obviously)

 * add the "GTY ((atomic))" option to field 'su' of struct 'function' in 
function.h
(that field is atomic, so you can mark it "atomic" and it should work)

 * rebuild everything from scratch (bootstrap the compiler)

 * gtype.state now contains, some time after (!pair "su", the lines

(!srcfileloc  "function.h" 516)

(!options
(!option atomic string  "")
)

btw, we should probably improve gtype.state; indentation would be nice :-) ...

 * gtype-desc.c now contains

void
gt_ggc_mx_function (void *x_p)
{
  struct function * const x = (struct function *)x_p;
  if (ggc_test_and_set_mark (x))
    {
      gt_ggc_m_9eh_status ((*x).eh);
      gt_ggc_m_18control_flow_graph ((*x).cfg);
      gt_ggc_m_12gimple_seq_d ((*x).gimple_body);
      gt_ggc_m_9gimple_df ((*x).gimple_df);
      gt_ggc_m_5loops ((*x).x_current_loops);
      if ((*x).su != NULL) {
        ggc_mark ((*x).su);
      }
      gt_ggc_m_9tree_node ((*x).decl);
      gt_ggc_m_9tree_node ((*x).static_chain_decl);
      gt_ggc_m_9tree_node ((*x).nonlocal_goto_save_area);
      gt_ggc_m_11VEC_tree_gc ((*x).local_decls);
      gt_ggc_m_16machine_function ((*x).machine);
      gt_ggc_m_17language_function ((*x).language);
      gt_ggc_m_P9tree_node4htab ((*x).used_types_hash);
    }
}

as you notice, the "su" field is only marked, but not followed.  Normally that 
same marking
function would be

void
gt_ggc_mx_function (void *x_p)
{
  struct function * const x = (struct function *)x_p;
  if (ggc_test_and_set_mark (x))
    {
      gt_ggc_m_9eh_status ((*x).eh);
      gt_ggc_m_18control_flow_graph ((*x).cfg);
      gt_ggc_m_12gimple_seq_d ((*x).gimple_body);
      gt_ggc_m_9gimple_df ((*x).gimple_df);
      gt_ggc_m_5loops ((*x).x_current_loops);
      gt_ggc_m_11stack_usage ((*x).su);
      gt_ggc_m_9tree_node ((*x).decl);
      gt_ggc_m_9tree_node ((*x).static_chain_decl);
      gt_ggc_m_9tree_node ((*x).nonlocal_goto_save_area);
      gt_ggc_m_11VEC_tree_gc ((*x).local_decls);
      gt_ggc_m_16machine_function ((*x).machine);
      gt_ggc_m_17language_function ((*x).language);
      gt_ggc_m_P9tree_node4htab ((*x).used_types_hash);
    }
}

which would call the gt_ggc_mx_stack_usage() function, which does nothing but 
mark the pointer in this case
(since the field actually is atomic), but would in other cases mark the 
children as well.  So, in this case
marking the field as "atomic" results in a small optimization when doing the GC 
marking stage.  In other cases,
when gengtype doesn't know how to inspect the memory pointed to (eg, "unsigned 
int *"), then it would make it
possible to use GC for the pointer.

PCH traversing is similar.

To test that the GC marking actually works, I mostly bootstrap the compiler 
first, then test compiling a few
testcases using --param ggc-min-expand=0 --param ggc-min-heapsize=0.  This is 
by no means a full test; if you
or Laurynas have any suggestions on how to test better, they'd be welcome. :-)

Thanks

Reply via email to