ARM/AAarch64: NEON intrinsics in the kernel

[Tejas Belagod]

Ard Biesheuvel wrote:
> On 18 July 2013 16:54, Tejas Belagod <tbelagod@arm.com> wrote:
>> I'd like to follow up this thread to move towards removing arm_neon.h's
>> dependence on stdint.h. My comments inline below.
>>
>>> As far as I can tell, the only dependency arm_neon.h has on the
>>> contents of that header are the [u]int[8|16|32|64]_t typedefs. The
>>> kernel does define those, only in a different header.
>>>
> 
> Hello Tejas,
> 
> What I did not realize at the time is that those types are part of the
> visible interface of the NEON intrinsics. Just as an example, there is
> a function in arm_neon.h:
> 
> uint8x8_t vset_lane_u8 (uint8_t __a, uint8x8_t __b, const int __c);
> 
> which clearly needs a type definition for uint8_t. Changing the
> published and documented interface is unlikely to be a realistic
> option, I'm afraid, and simply dropping the #include will cause
> breakage for some existing users, which is also not very appealing.
> 

I was thinking more on the lines of

#ifdef __INT8_TYPE__
typedef __INT8_TYPE__ int8_t;
#endif

and

#ifdef __UINT64_C
#define UINT64_C(c) __UINT64_C (c)
#endif

In other words this is perhaps reproducing a part of stdint-gcc.h. I don't know 
if there can be a situation when these are predefines are not defined ( eg. some 
-m option that turns them off?)

> Conditionally including stdint.h in case those types have not been
> defined (yet) would be the only remaining option, I think, but I am
> not sure if that is feasible.
> 

Are you proposing something like:

/* arm_neon.h */

#ifndef __intxx_t_defined ...
#define __STDC_CONSTANT_MACROS
#include <stdint.h>
#endif

...

/* Prevent __STDC_CONSTANT_MACROS from polluting the environment.  */
#ifdef __STDC_CONSTANT_MACROS
#undef __STDC_CONSTANT_MACROS
#endif

/* End of arm_neon.h */

Including all of stdint.h for only a few basic types/macros that we need seems 
to suggest to me that its too heavy a hammer, is it not?

Thanks,
Tejas.

> In the kernel case, I have worked around it by having a separate
> compilation unit containing the wrapped NEON intrinsics code, and
> using plain old C types to interface with the wrapper functions.
> 
> [...]
> 
> Regards,
> Ard.
>