This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: ARM/AAarch64: NEON intrinsics in the kernel
- From: David Brown <david at westcontrol dot com>
- To: Ard Biesheuvel <ard dot biesheuvel at linaro dot org>
- Cc: Tejas Belagod <tbelagod at arm dot com>, <gcc at gcc dot gnu dot org>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>, <christophe dot lyon at linaro dot org>, <matthew dot gretton-dann at linaro dot org>, Marcus Shawcroft <Marcus dot Shawcroft at arm dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, <joseph at codesourcery dot com>
- Date: Thu, 18 Jul 2013 18:24:29 +0200
- Subject: Re: ARM/AAarch64: NEON intrinsics in the kernel
- References: <CAKv+Gu-FaFnODdcVtdtrVsoJmE95vgdvcicRQ7N9_MvKuFXd8w at mail dot gmail dot com> <CAJA7tRb2KJsMqp7dSth8TVzmq=Z1=zzfro6co7PHwR_GxDW9gQ at mail dot gmail dot com> <51E801A7 dot 8010303 at arm dot com> <CAKv+Gu8hrWWpsz_xOoUpaWW5jtSX-sfegi9+qFQ8LvyS5RjRMA at mail dot gmail dot com>
On 18/07/13 17:22, 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.
>
> 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.
>
> 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.
>
Since you need definitions of uint8_t and friends, and they can come
from either linux/types.h or stdint.h, why not check both?
#ifdef _LINUX_TYPES_H
// We have the types from <linux/types.h>
#else
#ifdef _STDINT_H
// We have them from <stdint.h>
#else
#include <stdint.h>
// or #include <linux/types.h>
#endif
#endif
(I don't know which header is preferred for the default include).