Re: [PATCH v3 1/8] rs6000: More factoring of overload processing

[Segher Boessenkool <segher@kernel.crashing.org>]

Hi!

On Thu, Feb 03, 2022 at 08:44:48AM -0600, Bill Schmidt wrote:
> Although the previous patch was correct, the logic around what to do when
> the number of arguments is wrong was still hard to understand.  It should
> be better now.  I'm now explicitly counting the number of expected arguments
> and comparing against that.  The way the argument list is represented ensures
> there is always at least one element in the argument chain, by terminating
> the chain with an argument type of void, which is why the previous logic was
> so convoluted.

Aha :-)

> +  /* Count the number of expected arguments.  */
> +  unsigned expected_args = 0;
> +  for (tree chain = fnargs;
> +       chain && !VOID_TYPE_P (TREE_VALUE (chain));
> +       chain = TREE_CHAIN (chain))
> +    expected_args++;

FOREACH_FUNCTION_ARGS?

> +    So even though __builtin_vec_splats accepts all vector types, the
> +    infrastructure cheats and just records one prototype.  We end up getting
> +    an error message that refers to this specific prototype even when we
> +    are handling a different argument type.  That is completely confusing
> +    to the user, so it's best to let these cases be handled individually
> +    in the resolve_vec_splats, etc., helper functions.  */
> +
> +  if (n != expected_args
> +      && !(fcode == RS6000_OVLD_VEC_PROMOTE
> +	   || fcode == RS6000_OVLD_VEC_SPLATS
> +	   || fcode == RS6000_OVLD_VEC_EXTRACT
> +	   || fcode == RS6000_OVLD_VEC_INSERT
> +	   || fcode == RS6000_OVLD_VEC_STEP))
>      return NULL;

Even I can understand that!  Thank you! :-)

Okay for trunk.


Segher