This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ARM/AAarch64: NEON intrinsics in the kernel


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.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]