Understanding arm_sve.h

[Kyrylo Tkachov]

Hi David,

> On 15 Jan 2025, at 13:33, David Aldrich via Gcc-help <gcc-help@gcc.gnu.org> wrote:
> 
> Hi
> 
> The gcc Arm compiler aarch64-linux-gnu (v14) provides the following
> Arm intrinsics header file:
> 
> \usr\lib\gcc\aarch64-linux-gnu\14\include\arm_sve.h
> 
> However,  this header file uses a pragma to generate the definitions:
> 
> /* NOTE: This implementation of arm_sve.h is intentionally short.  It does
>   not define the SVE types and intrinsic functions directly in C and C++
>   code, but instead uses the following pragma to tell GCC to insert the
>   necessary type and function definitions itself.  The net effect is the
>   same, and the file is a complete implementation of arm_sve.h.  */
> #pragma GCC aarch64 "arm_sve.h"
> 
> I don't understand how this works.
> 

The idea is that rather than implementing every ACLE intrinsic as a wrapper around an builtin, annotated with attributes like always_inline etc the compiler injects
the necessary intrinsic definitions directly into the language when it encounters this aarch64-specific pragma.
This has a number of advantages, among others:
* It avoids having to parse a large regular .h file during compilation
* It allows the compiler to handle some of the more elaborate features of SVE intrinsics such as overloading and type deduction during name resolution.
* It allows for more powerful custom validation of intrinsic arguments (like enforcing strict compile-time literal arguments for vector lanes) and more helpful error message

> I would like to inspect the actual definitions of the intrinsics. Is
> it possible to view the actual definitions?
> 

The downside is there’s no single self-contained file that interested readers can look at.
You can find the code that creates these definitions for SVE in the GCC source in the files named aarch64-sve-builtins-*.cc under the gcc/config/aarch64 subdirectory:
https://gcc.gnu.org/git/?p=gcc.git;a=tree;f=gcc/config/aarch64;h=7f0aea8187549eefa9c3c6d046a3f56183dc2a69;hb=HEAD

Thanks,
Kyrill

> Best regards
> David