Change __ARM_NEON_SVE_BRIDGE to refer to the availability of the head…

…er (#362)

**Afterthought**: Another way of looking at this is that the user should
not expect to be able to use intrinsics after specifying the relevant
target features via anything other than the command line, it's unclear
to me if this is the case.

The ACLE suggests the use of the predefined `__ARM_NEON_SVE_BRIDGE`
macro to gaurd the inclusion of `arm_neon_sve_bridge.h`.

><arm_neon_sve_bridge.h> defines intrinsics for moving data between Neon
and SVE vector types; see [NEON-SVE
Bridge](https://github.com/ARM-software/acle/blob/main/main/acle.md#neon-sve-bridge)
for details. Before including the header, you should test the
__ARM_NEON_SVE_BRIDGE macro.

The current definition of this macro is
>`__ARM_NEON_SVE_BRIDGE` is defined to 1 if [NEON-SVE
Bridge](#neon-sve-bridge)
intrinsics are available. This implies that the following macros are
nonzero
>  -  __ARM_NEON
> - __ARM_NEON_FP
>  -  __ARM_FEATURE_SVE

The intrinsics described here are not preprocessor guarded (See [change
for LLVM]( https://reviews.llvm.org/D132639)). We should expect to be
able to use them in any function with the necessary features, whether
they are supplied globally on the command line or via a `target`
attribute.

However, since we cannot make assumptions about the order in which the
predefined feature macros are evaluated (see [relevant
ACLE](https://github.com/ARM-software/acle/blob/main/main/acle.md#predefined-feature-macros-and-header-file)),
we cannot use the `__ARM_NEON_SVE_BRIDGE` macro to guard the inclusion
of `arm_neon_sve_bridge.h` **and** expect to use it's builtins in unless
the required features are supplied globally on the command line.

See an example of this issue (in LLVM Vs. GCC) from @georges-arm -
https://godbolt.org/z/6YPvqdjTv.

The proposal of this PR is to change the meaning of
`__ARM_NEON_SVE_BRIDGE` to refer to the availability of the
`arm_neon_sve_bridge.h` header file only, such that it can be
unconditionally defined in supporting compilers and it's builtins can be
safely used in the context of the example above.

main/acle.md

@@ -241,7 +241,7 @@ Armv8.4-A [[ARMARMv84]](#ARMARMv84). Support is added for the Dot Product intrin
   specifications in [Cortex-M Security Extension
   (CMSE)](#cortex-m-security-extension-cmse).
 * Added specification for [NEON-SVE Bridge](#neon-sve-bridge) and
-  [NEON-SVE Bridge macros](#neon-sve-bridge-macros).
+  [NEON-SVE Bridge macros](#neon-sve-bridge-macro).
 * Added feature detection macro for the memcpy family of memory
   operations (MOPS) at [memcpy family of memory operations
   standarization instructions -
@@ -425,6 +425,9 @@ Armv8.4-A [[ARMARMv84]](#ARMARMv84). Support is added for the Dot Product intrin
 * Removed unnecessary Zd argument from `svcvtnb_mf8[_f32_x2]_fpm`.
 * Fixed urls.
 * Changed name mangling of function types to include SME attributes.
+* Changed `__ARM_NEON_SVE_BRIDGE` to refer to the availability of the
+  [`arm_neon_sve_bridge.h`](#arm_neon_sve_bridge.h) header file, rather
+  than the [NEON-SVE bridge](#neon-sve-bridge) intrinsics.
 
 ### References
 
@@ -1928,14 +1931,10 @@ are available. This implies that `__ARM_FEATURE_SVE` is nonzero.
  are available and if the associated [ACLE features]
 (#sme-language-extensions-and-intrinsics) are supported.
 
-#### NEON-SVE Bridge macros
+#### NEON-SVE Bridge macro
 
-`__ARM_NEON_SVE_BRIDGE` is defined to 1 if [NEON-SVE Bridge](#neon-sve-bridge)
-intrinsics are available. This implies that the following macros are nonzero:
-
-* `__ARM_NEON`
-* `__ARM_NEON_FP`
-* `__ARM_FEATURE_SVE`
+`__ARM_NEON_SVE_BRIDGE` is defined to 1 if the [`<arm_neon_sve_bridge.h>`](#arm_neon_sve_bridge.h)
+header file is available.
 
 #### Scalable Matrix Extension (SME)
 
@@ -2570,7 +2569,7 @@ be found in [[BA]](#BA).
 | [`__ARM_FP_FENV_ROUNDING`](#floating-point-model)                                                                                                       | Rounding is configurable at runtime                                                                | 1           |
 | [`__ARM_NEON`](#advanced-simd-architecture-extension-neon)                                                                                              | Advanced SIMD (Neon) extension                                                                     | 1           |
 | [`__ARM_NEON_FP`](#neon-floating-point)                                                                                                                 | Advanced SIMD (Neon) floating-point                                                                | 0x04        |
-| [`__ARM_NEON_SVE_BRIDGE`](#neon-sve-bridge-macros)                                                                                                      | Moving data between Neon and SVE data types                                                        | 1           |
+| [`__ARM_NEON_SVE_BRIDGE`](#neon-sve-bridge-macro)                                                                                                       | Availability of [`arm_neon_sve_brdge.h`](#arm_neon_sve_bridge.h)                                   | 1           |
 | [`__ARM_PCS`](#procedure-call-standard)                                                                                                                 | Arm procedure call standard (32-bit-only)                                                          | 0x01        |
 | [`__ARM_PCS_AAPCS64`](#procedure-call-standard)                                                                                                         | Arm PCS for AArch64.                                                                               | 1           |
 | [`__ARM_PCS_VFP`](#procedure-call-standard)                                                                                                             | Arm PCS hardware FP variant in use (32-bit-only)                                                   | 1           |