Add a combined_fn enum

[Richard Sandiford]

Bernd Schmidt <bschmidt@redhat.com> writes:
> On 11/09/2015 03:57 PM, Richard Sandiford wrote:
>
>> I'm not sure what you mean by "fix" though.  I don't think we can change
>> any of the constraints above.
>
> I don't see why they couldn't be relaxed. What's stopping us from 
> defining some builtins independently of the frontends, and don't all 
> languages except Fortran use the normal builtins.def anyway?

I think the problem isn't so much with the functions that we define
ourselves as those that simply mirror a standard library function.
We can't assume that all the libm functions exist.  It's also valid
for the implementation to add target-specific attributes on top of
what the standard says (e.g. "nomips16" on MIPS).

So if a call starts out as a call to sinf and we treat it as a call to
__builtin_sinf for optimisation purposes, there is always conceptually
an underlying "physical" sinf function.  We also can't convert calls
to __builtin_sin to calls to __builtin_sinf without proof that a sinf
definition exists (not guaranteed for C90).

> Also - if you can have an internal function without a fndecl, why
> wouldn't it work to allow that for builtins as well? But this is
> probably moot since I can now see a little more clearly what you want
> to do.

I think that's the defining characteristic of builtins vs. internal
functions though.  built-in functions are directly callable by source
code and have a defined function signature.  Internal functions are not
directly callable by source code and have a flexible function signature.

There are cases where this difference doesn't matter, which is why
the combined_fn enum seemed like a good idea.  But I don't think we
can do away with the distinction entirely.

>> The main goal is to allow functions to be vectorised simply by defining
>> the associated optab.
>
> Ok. So these internal functions would support arbitrary modes like 
> V[1248][SDX]F etc., unlike the builtins?

Yeah.  They also never set errno.

> That wasn't entirely clear from the patches I looked at, it seemed
> like you were just duplicating every builtin as an internal function
> (something to which I would have objected).

Yeah, sorry about that.  I'll post the patches shortly.

Thanks,
Richard