This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH RFC: Implement and use VEC(T,stack)


Paolo Bonzini <paolo.bonzini@gmail.com> writes:

> +   #define VEC_{TYPE}_stack_alloc(alloc)                          \
> +    (VEC_op(df_ref,stack,alloc1)                                  \
> +     (alloc,                                                      \
> +      XALLOCAVAR (VEC({TYPE},stack),                              \
> +                  VEC_embedded_size ({TYPE}, alloc))))
>
> There's a pasto in these docs (df_ref).  Also you can do
>
> #define VEC_stack_alloc(TYPE, ALLOC) \
>   (VEC_op(TYPE,stack,alloc1) (ALLOC, \
>         XALLOCAVAR (VEC(TYPE, stack), VEC_embedded_size (TYPE, ALLOC))))
>
> and define just
>
> #define VEC_df_ref_stack_alloc(ALLOC) VEC_stack_alloc(df_ref, (ALLOC))
>
> which is (only a bit) nicer.

Thanks for the looking at the patch and thanks for the suggestions.  I
will do that.

> Also, please use a pointer_set as it has
> less overhead (maybe even a linear scan would do, we don't expect
> these vectors to live long do we??).

I didn't use a pointer_set because there is no pointer_set_delete.  And
there is no pointer_set_delete because it's nontrivial to write in a way
which makes pointer_sets stay efficient when there is a sequence of
inserts and deletes.

I wouldn't expect these vectors to live a long time but a linear scan
seems risky to me.  That would probably be enough to make somebody to
write a deeply recursive function using VEC(T,stack).

Ian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]