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: Tejas Belagod <tbelagod at arm dot com>
- To: Ard Biesheuvel <ard dot biesheuvel at linaro dot org>
- Cc: Tejas Belagod <Tejas dot Belagod at arm dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>, "christophe dot lyon at linaro dot org" <christophe dot lyon at linaro dot org>, "matthew dot gretton-dann 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" <joseph at codesourcery dot com>
- Date: Thu, 18 Jul 2013 18:17:12 +0100
- 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>
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.