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
