ARM/AAarch64: NEON intrinsics in the kernel

ARM/AAarch64: NEON intrinsics in the kernel

[Ard Biesheuvel]

Hello all,

I am currently exploring various ways of using NEON instructions in
kernel mode. One of the ways of doing so is using NEON intrinsics,
which we would like to support in the kernel, but unfortunately, at
the moment we can't because the support header arm_neon.h assumes C99
conformance and includes <stdint.h>. The kernel does not supply that
header.

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.

I would like to propose the following way to address this issue: as
arm_neon.h is coupled very tightly with GCC's internals
(__builtin_neon_* types and functions), could we not modify arm_neon.h
to
- drop the #include <stdint.h>
- replace every instance of [u]intxx_t with the builtin macro
__[U]INTxx_TYPE__ (as we are already dependent on specific versions of
GCC, this should not introduce any additional limitations)

In this way, it is much easier to support NEON intrinsics in
environments that we care about (like the kernel) but do not conform
to the standards.

Kind regards,
Ard.

Re: ARM/AAarch64: NEON intrinsics in the kernel

[Richard Earnshaw]

On 21/05/13 10:32, Ard Biesheuvel wrote:
> Hello all,
>
> I am currently exploring various ways of using NEON instructions in
> kernel mode. One of the ways of doing so is using NEON intrinsics,
> which we would like to support in the kernel, but unfortunately, at
> the moment we can't because the support header arm_neon.h assumes C99
> conformance and includes <stdint.h>. The kernel does not supply that
> header.
>
> 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.
>
> I would like to propose the following way to address this issue: as
> arm_neon.h is coupled very tightly with GCC's internals
> (__builtin_neon_* types and functions), could we not modify arm_neon.h
> to
> - drop the #include <stdint.h>
> - replace every instance of [u]intxx_t with the builtin macro
> __[U]INTxx_TYPE__ (as we are already dependent on specific versions of
> GCC, this should not introduce any additional limitations)
>
> In this way, it is much easier to support NEON intrinsics in
> environments that we care about (like the kernel) but do not conform
> to the standards.
>
> Kind regards,
> Ard.
>

Why don't you add a (maybe cut-down) stdint.h to the kernel.  It seems 
bizarre to me that the kernel is trying to provide standard types 
through a non-standard interface.

R.

Re: ARM/AAarch64: NEON intrinsics in the kernel

[Ard Biesheuvel]

On 21 May 2013 11:43, Richard Earnshaw <rearnsha@arm.com> wrote:
> Why don't you add a (maybe cut-down) stdint.h to the kernel.  It seems
> bizarre to me that the kernel is trying to provide standard types through a
> non-standard interface.
>

There have been heated debates going on for years about these things.

Quote from Linus Torvalds: (http://yarchive.net/comp/linux/kernel_headers.html)

"
The user is supposed to see "int32_t" and friends _only_ if the user
himself includes <stdint.h> or one of the very specific headers that is
documented by the standard to include it.

Trust me. We are NOT going to use <stdint.h> in the kernel.
"

This is fairly old, and some of the types have in fact been added to
<linux/types.h>, even if stdint.h is still absent.

The bottom line is that including arm_neon.h pulls in a host of stuff
into the namespace, even with -ffreestanding. (And in that case, the
fact that GCC built for bare metal and GCC built for GLIBC disagree on
the definition of __UINTPTR_TYPE__ is not helping a lot either)

I understand that the uintXX_t types have already been made part of
the public NEON instrinsics interface, so I am not proposing changing
that. I am just looking for a way to enable the use of NEON intrinsics
in the kernel.

Are there any other solution possible in your opinion? Do you agree
that POSIX states that stdint.h may only be included in specific well
defined cases? Could we perhaps make the #inclusion conditional? An
alternate header perhaps to accomodate non-C99 environments?

Regards,
Ard.

Re: ARM/AAarch64: NEON intrinsics in the kernel

[Joseph S. Myers]

On Tue, 21 May 2013, Ard Biesheuvel wrote:

> I am currently exploring various ways of using NEON instructions in
> kernel mode. One of the ways of doing so is using NEON intrinsics,
> which we would like to support in the kernel, but unfortunately, at
> the moment we can't because the support header arm_neon.h assumes C99
> conformance and includes <stdint.h>. The kernel does not supply that
> header.

GCC, however, does, and for Linux targets it installs stdint-wrap.h which 
for freestanding builds includes stdint-gcc.h rather than depending on the 
C library to provide the header.  So as long as the kernel build uses 
-ffreestanding, it should not matter that the kernel doesn't have its own 
stdint.h.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: ARM/AAarch64: NEON intrinsics in the kernel

[Ard Biesheuvel]

On 21 May 2013 18:22, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Tue, 21 May 2013, Ard Biesheuvel wrote:
>
>> I am currently exploring various ways of using NEON instructions in
>> kernel mode. One of the ways of doing so is using NEON intrinsics,
>> which we would like to support in the kernel, but unfortunately, at
>> the moment we can't because the support header arm_neon.h assumes C99
>> conformance and includes <stdint.h>. The kernel does not supply that
>> header.
>
> GCC, however, does, and for Linux targets it installs stdint-wrap.h which
> for freestanding builds includes stdint-gcc.h rather than depending on the
> C library to provide the header.  So as long as the kernel build uses
> -ffreestanding, it should not matter that the kernel doesn't have its own
> stdint.h.
>

I am aware of that. However, depending on whether your GCC was built
to target bare metal or glibc, the definition for uintptr_t that you
get as a bonus from including stdint-gcc.h (a type which arm_neon.h
itself does not require) conflicts with the one that the kernel
defines. (bare metal and the kernel both use unsigned long, whereas
glibc uses unsigned int) As it is quite customary to use a glibc
targeted GCC to build the kernel, I would like to avoid being the one
to introduce the restriction that only bare metal compilers can build
the kernel. (Note that the kernel does not define -ffreestanding by
default, although it mostly compiles fine with it)

-- 
Ard.

Re: ARM/AAarch64: NEON intrinsics in the kernel

[Tejas Belagod]

Hi Ard,

I'd like to follow up this thread to move towards removing arm_neon.h's 
dependence on stdint.h. My comments inline below.

> From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Date: Tue, May 21, 2013 at 10:32 AM
> Subject: ARM/AAarch64: NEON intrinsics in the kernel
> To: gcc@gcc.gnu.org
> Cc: Christophe Lyon <christophe.lyon@linaro.org>, Matthew Gretton-Dann
> <matthew.gretton-dann@linaro.org>, richard.earnshaw@arm.com,
> ramana.radhakrishnan@arm.com, marcus.shawcroft@arm.com
> 
> 
> Hello all,
> 
> I am currently exploring various ways of using NEON instructions in
> kernel mode. One of the ways of doing so is using NEON intrinsics,
> which we would like to support in the kernel, but unfortunately, at
> the moment we can't because the support header arm_neon.h assumes C99
> conformance and includes <stdint.h>. The kernel does not supply that
> header.
> 
> 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.
> 

There are also constant macros like UINT64_C etc that cause issues when compiled 
with C++. Also, defining __STDC_CONSTANT_MACROS to get around this issue is 
won't make the problem go away, I think.

> I would like to propose the following way to address this issue: as
> arm_neon.h is coupled very tightly with GCC's internals
> (__builtin_neon_* types and functions), could we not modify arm_neon.h
> to
> - drop the #include <stdint.h>

Removing arm_neon.h's dependency on stdint.h is probably a good idea.

> - replace every instance of [u]intxx_t with the builtin macro
> __[U]INTxx_TYPE__ (as we are already dependent on specific versions of
> GCC, this should not introduce any additional limitations)
> 

The choice we have to do this is replacing all the stdint types with the 
predefined macros

<u>int<8,16,32,64>_t with predefined __<U>INT<8,16,32,64>_TYPE__
and
UINT64_C from stdint.h with __UINT64_C etc.

But it is recommended that these never be used directly - only via the header. 
If we use these directly in arm_neon.h, it introduces a dependency with the 
predefines implementation in gcc, but as you point out that arm_neon.h is 
already dependent on the specific versions of gcc, this maintainance overhead is 
probably unavoidable. We do need standard typedefs from somewhere...

Thoughts?

Thanks,
Tejas Belagod.
ARM.


> In this way, it is much easier to support NEON intrinsics in
> environments that we care about (like the kernel) but do not conform
> to the standards.
> 
> Kind regards,
> Ard.
> 

Re: ARM/AAarch64: NEON intrinsics in the kernel

[Ard Biesheuvel]

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.

Re: ARM/AAarch64: NEON intrinsics in the kernel

[David Brown]

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).

Re: 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.
>