Variadic templates, fourth revision [Committed]

[Doug Gregor]

Richard, thank you for looking into this!

On 3/11/07, Richard Guenther <richard.guenther@gmail.com> wrote:
> May I suggest to change
>
> struct template_parm_index_s GTY(())
> {
>   struct tree_common common;
>   HOST_WIDE_INT index;
>   HOST_WIDE_INT level;
>   HOST_WIDE_INT orig_level;
>   tree decl;
>
>   /* When true, indicates that this parameter is actually a parameter
>      pack, for variadic templates.  */
>   BOOL_BITFIELD parameter_pack;
> };
>
> to
>
> struct template_parm_index_s GTY(())
> {
>   struct tree_common common;
>   int index;
>   int level;
>   int orig_level;
>
>   /* When true, indicates that this parameter is actually a parameter
>      pack, for variadic templates.  */
>   BOOL_BITFIELD parameter_pack;
>
>   tree decl;
> };
>
> to allow for better packing on 64bit hosts.  Maybe even shortening
> index and levels even more dependent on their use.  At least use
> HOST_WIDE_FAST_INT (avoid long long on 32bit host with 64bit hwi).

All very good ideas. I've seen some absolutely crazy C++ template
code, but none of it needed more than 2^31 template parameters (or
even 2^15 template parameters) :)

Additionally, I realized that that the parameter_pack flag could
instead use  TREE_LANG_FLAG_0, which is not yet taken for
TEMPLATE_PARM_INDEX nodes.

> @@ -3812,6 +3908,9 @@ struct cp_declarator {
>       cdk_id and cdk_error, guaranteed to be NULL.  */
>    cp_declarator *declarator;
>    location_t id_loc; /* Currently only set for cdk_id. */
> +  /* Whether we parsed an ellipsis (`...') just before the declarator,
> +     to indicate this is a parameter pack.  */
> +  bool parameter_pack_p;
>    union {
>      /* For identifiers.  */
>      struct {
>
> This is bad.  We can easily pack this together with the kind member:
>
> /* A declarator.  */
> struct cp_declarator {
>   /* The kind of declarator.  */
>   cp_declarator_kind kind : 4;
>   unsigned parameter_pack_p : 1;
> ...
>
> if there's no memleaks involved with the patch the above should solve
> the regressions, no?

Yes, it should. Those are the only two data structures that grew with
the variadic templates patch.

> There's more low-hanging fruit in cp-tree.h though...
>
> struct saved_scope GTY(())
> {
> ...
>   HOST_WIDE_INT x_processing_template_decl;
>   int x_processing_specialization;
>   bool x_processing_explicit_instantiation;
>   int need_pop_function_context;
>   bool skip_evaluation;
> ...
>
> yuck!

Perhaps in the context of cleaning up the memory usage regression
introduced with the variadic templates patch, I could do a quick
survery of cp-tree.h to see what else can safely/easily be done.

  Cheers,
  Doug