This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Generic return types in built-in functions (C frontend)
- From: Richard Guenther <richard dot guenther at gmail dot com>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: Artem Shinkarov <artyom dot shinkaroff at gmail dot com>, gcc <gcc at gcc dot gnu dot org>, "Joseph S. Myers" <joseph at codesourcery dot com>
- Date: Tue, 29 Jun 2010 11:32:32 +0200
- Subject: Re: Generic return types in built-in functions (C frontend)
- References: <AANLkTikXBf2axNEDjzx54FM90g66xc1dWuVVIzv4nqCj@mail.gmail.com> <mcrmxue90gz.fsf@google.com>
On Tue, Jun 29, 2010 at 1:55 AM, Ian Lance Taylor <iant@google.com> wrote:
> Artem Shinkarov <artyom.shinkaroff@gmail.com> writes:
>
>> I'm trying to implement a support for vector shuffling. For this
>> purpose I would like to introduce a built-in function and lower it
>> down in the veclower pass. However the problem is, that I don't want
>> to introduce a separate built-in function for each type. So the
>> question is: how can I specify a built-in function that would accept
>> any parameters, and would be expanded at some points to some proper
>> types. There is a hacky solution like in this patch:
>> http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00096.html, but may be
>> someone have an idea of a cleaner solution.
>
> Perhaps you could define the builtin function as a pure varargs
> function, and do the appropriate type checking manually when folding the
> call.
We already to that (varargs function) for the type-generic C99 fp
classification functions (and use attribute "type generic" to mark them,
especially to avoid applying default conversions for vararg calls).
The type-generic C99 fp classification functions are a somewhat
simple case though as they all have a fixed return type, int.
For the case in question we need a return type that is determined
by the function argument type(s). Thus there is both the complexity
of teaching that to the FE and the middle-end.
Richard.
> Ian
>