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.biesheu...@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.l...@linaro.org>, Matthew Gretton-Dann
<matthew.gretton-d...@linaro.org>, richard.earns...@arm.com,
ramana.radhakrish...@arm.com, marcus.shawcr...@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.
