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: [SVE ACLE] Add initial support for arm_sve.h


Richard Biener <richard.guenther@gmail.com> writes:
> On Wed, Jul 18, 2018 at 8:08 PM Richard Sandiford
> <richard.sandiford@arm.com> wrote:
>>
>> This patch adds the target framework for handling the SVE ACLE,
>> starting with four functions: svadd, svptrue, svsub and svsubr.
>>
>> The ACLE has both overloaded and non-overloaded names.  Without
>> the equivalent of clang's __attribute__((overloadable)), a header
>> file that declared all functions would need three sets of declarations:
>>
>> - the non-overloaded forms (used for both C and C++)
>> - _Generic-based macros to handle overloading in C
>> - normal overloaded inline functions for C++
>>
>> This would likely require a lot of cut-&-paste.  It would probably
>> also lead to poor diagnosics and be slow to parse.
>>
>> Another consideration is that some functions require certain arguments
>> to be integer constant expressions.  We can (sort of) enforce that
>> for calls to built-in functions using resolve_overloaded_builtin,
>> but it would be harder to enforce with inline forwarder functions.
>>
>> For these reasons and others, the patch takes the approach of adding
>> a pragma that gets the compiler to insert the definitions itself.
>> This requires a slight variation on the existing lang hooks for
>> built-in functions, but otherwise it seems to just work.
>
> I guess you did consider auto-generating the three variants from a template?

Yeah.  But that would only solve the cut-&-paste problem, not the others.
It would also be quite a lot more complicated overall.

E.g. scripting code to produce the right _Generics is much more complicated
than just implementing the overloading using resolve_overloaded_builtin
(which also produces better error messages).  And even just scripting
the declarations is more work: the backend has to register a built-in
function either way, so getting it to register the public name is
easier than having the backend register a __builtin_ function and
then scripting a header file declaration with the same prototype
and attributes.

Thanks,
Richard


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