Nathan Froyd wrote:

>        for (parm = 1; d->parm[parm] != SPU_BTI_END_OF_PARAMS; parm++)
>       ;
>  
> -      p = void_list_node;
> +      gcc_assert (parm <= (SPU_MAX_ARGS_TO_BUILTIN + 1));
> +
> +      for (i = 0; i < ARRAY_SIZE (args); i++)
> +     args[i] = NULL_TREE;
> +
>        while (parm > 1)
> -     p = tree_cons (NULL_TREE, spu_builtin_types[d->parm[--parm]], p);
> +     {
> +       tree arg = spu_builtin_types[d->parm[--parm]];
> +       args[parm-1] = arg;
> +     }
>  
> -      p = build_function_type (spu_builtin_types[d->parm[0]], p);
> +      ftype = build_function_type_list (spu_builtin_types[d->parm[0]],
> +                                     args[0], args[1], args[2], NULL_TREE);

This looks really odd now.  The reason for running through parms twice,
first forwards and then backwards, is just that you need build up the
linked tree using tree_cons from the end.

With the new scheme, all of that is now unnecessary.  Why not simply
something along the lines of:

  for (i = 0; i < ARRAY_SIZE (args) && d->parm[i] != SPU_BTI_END_OF_PARAMS; i++)
    args[i] = spu_builtin_types[d->parm[i]];

  for (; i < ARRAY_SIZE (args); i++)
    args[i] = NULL;

  ftype = build_function_type_list (args[0], args[1], args[2], args[3], 
NULL_TREE);

(As an aside, the SPU_MAX_ARGS_TO_BUILTIN define appears to imply a generality
that is not really there: the call to build_function_type in itself implies an
upper bound on the number of supported arguments.)

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  ulrich.weig...@de.ibm.com

Reply via email to