On Thu, 2014-08-07 at 13:32 +0200, Bernd Schmidt wrote:
> On 08/06/2014 07:23 PM, David Malcolm wrote:
> > diff --git a/gcc/function.h b/gcc/function.h
> > index 28a20f3..ba7597c 100644
> > --- a/gcc/function.h
> > +++ b/gcc/function.h
> > @@ -135,7 +135,7 @@ struct GTY(()) expr_status {
> >     rtx x_apply_args_value;
> >
> >     /* List of labels that must never be deleted.  */
> > -  rtx x_forced_labels;
> > +  rtx_expr_list *x_forced_labels;
> >   };
> >
> 
> As I said at the Cauldron, this sort of thing seems like the wrong thing 
> to do - when eliminating our own ancient list implementations we should 
> just go to normal C++ such as list<rtx>, or maybe even just a vec in 
> this case and some others. This applies to both expr_list and insn_list 
> - in the end we really shouldn't have either rtx_expr_list or rtx_insn_list.

Thanks.

As I see it, if we want to eliminate EXPR_LIST, INSN_LIST (and
INT_LIST?) in favor of more optimal data structures, then identifying
everywhere they're used seems to me like a good first step, and that's
one of the benefits of these patches.

These patches don't fundamentally change the data structures we're
currently using - they just make them more visible.

As an experiment, I've now tried converting forced_labels to a different
data structure: from an EXPR_LIST to a:
  vec<rtx_code_label *, va_gc> *

I'm attaching the result (I haven't bootstrapped it yet, though it does
compile and run OK on a simple testcase).

I don't know if such a change is an improvement (perhaps a set would be
better than a list, to get better than O(N) when determining if a label
is forced?), but my feeling is that the patchkit makes this kind of
experimentation *much* easier, since
it highlights where we're using EXPR_LIST, thus suggesting targets for
data structure overhauls.

Dave