Re: Add a simulate_builin_function_decl langhook

[Jeff Law <law at redhat dot com>]

On 9/26/19 6:04 AM, Richard Sandiford wrote:
> Although it's possible to define the SVE intrinsics in a normal header
> file, it's much more convenient to define them directly in the compiler.
> This also speeds up compilation and gives better error messages.
> 
> The idea is therefore for arm_sve.h (the main intrinsics header file)
> to have the pragma:
> 
>     #pragma GCC aarch64 "arm_sve.h"
> 
> telling GCC to define (almost) everything arm_sve.h needs to define.
> The target then needs a way of injecting new built-in function
> declarations during compilation.
> 
> The main hook for defining built-in functions is add_builtin_function.
> This is designed for use at start-up, and so has various features that
> are correct in that context but not for the pragma above:
> 
>   (1) the location is always BUILTINS_LOCATION, whereas for arm_sve.h
>       it ought to be the location of the pragma.
> 
>   (2) the function is only immediately visible if it's in the implementation
>       namespace, whereas the pragma is deliberately injecting functions
>       into the general namespace.
> 
>   (3) there's no attempt to emulate a normal function declaration in
>       C or C++, whereas functions declared by the pragma should be
>       checked in the same way as an open-coded declaration would be.
>       E.g. we should get an error if there was a previous incompatible
>       declaration.
> 
>   (4) in C++, the function is treated as extern "C" and so can't be
>       overloaded, whereas SVE intrinsics do use function overloading.
> 
> This patch therefore adds a hook that targets can use to inject
> the equivalent of a source-level function declaration, but bound
> to a BUILT_IN_MD function.
> 
> The main SVE intrinsic patch has tests to make sure that we report an
> error for conflicting definitions that appear either before or after
> including arm_sve.h.
> 
> Tested on aarch64-linux-gnu and x86_64-linux-gnu.  OK to install?
I'm struggling to see how this is significantly better than a suitable
arm_sve.h file.    Can you walk me through more of the motivation side?

jeff