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] use build_function_type_list in the spu backend


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.Weigand@de.ibm.com


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