[AArch64][Clang] Internal Neon types missing in Clang

[rj-jesus]

The AAPCS64, Appendix 11 (Neon) states that:

The AARCH64 architecture supports a number of short-vector operations. To facilitate accessing these types from C and C++ a number of extended types need to be added to the language.

Following the conventions used for adding types to C99 a number of additional types (internal types) are defined unconditionally.

These internal types are copied below:

Internal type (8)	Internal type (16)	Internal type (32)	Internal type (64)
__Int8x8_t	__Int16x4_t	__Int32x2_t
__Uint8x8_t	__Uint16x4_t	__Uint32x2_t
	__Float16x4_t	__Float32x2_t
__Poly8x8_t	__Poly16x4_t
	__Bfloat16x4_t
__Int8x16_t	__Int16x8_t	__Int32x4_t	__Int64x2_t
__Uint8x16_t	__Uint16x8_t	__Uint32x4_t	__Uint64x2_t
	__Float16x8_t	__Float32x4_t	__Float64x2_t
__Poly8x16_t	__Poly16x8_t		__Poly64x2_t
	__Bfloat16x8_t

Appendix 12 defines similar SVE types, such as __SVUint8_t and __SVBool_t.

While Clang defines the SVE types, it does not define the Neon types.
GCC defines both. https://godbolt.org/z/jjG9vbj85

Should Clang be defining the internal Neon types?

[llvmbot]

@llvm/issue-subscribers-backend-aarch64

Author: Ricardo Jesus (rj-jesus)

The [AAPCS64, Appendix 11](https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#11appendix-support-for-advanced-simd-extensions) (Neon) states that: > The AARCH64 architecture supports a number of short-vector operations. To facilitate accessing these types from C and C++ a number of extended types need to be added to the language. > > Following the conventions used for adding types to C99 a number of additional types (internal types) are defined unconditionally.

These internal types are copied below:

Internal type (8)	Internal type (16)	Internal type (32)	Internal type (64)
__Int8x8_t	__Int16x4_t	__Int32x2_t
__Uint8x8_t	__Uint16x4_t	__Uint32x2_t
	__Float16x4_t	__Float32x2_t
__Poly8x8_t	__Poly16x4_t
	__Bfloat16x4_t
__Int8x16_t	__Int16x8_t	__Int32x4_t	__Int64x2_t
__Uint8x16_t	__Uint16x8_t	__Uint32x4_t	__Uint64x2_t
	__Float16x8_t	__Float32x4_t	__Float64x2_t
__Poly8x16_t	__Poly16x8_t		__Poly64x2_t
	__Bfloat16x8_t

Appendix 12 defines similar SVE types, such as __SVUint8_t and __SVBool_t.

While Clang defines the SVE types, it does not define the Neon types.
GCC defines both. https://godbolt.org/z/jjG9vbj85

Should Clang be defining the internal Neon types?

[mgabka]

@rj-jesus it looks like a bug in clang which has been there forever.
I think the expectation is that since these are internal only types they should never be used by developers. However the ACLE spec us clear that these types are unconditional, while the other types could in theory be guarded by corresponding feature macros (however since now we need to support also Function Multiversioning, in practice the arm_neon types need to be also defined unconditionally).

[rj-jesus]

Hi @mgabka, thanks very much for the confirmation. I came across this in a header file where these types were being used specifically to avoid including arm_neon and potentially polluting the user's namespace.
Do you know if there are any plans to address this in clang? Should I leave this ticket open to track this? Thanks again.

[rj-jesus]

This was fixed in #126945 and #142760, so I'm closing it.
Thanks very much for sorting this out!