This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: ARM NEON Intrinsics guide?
- From: Kyrill Tkachov <kyrylo dot tkachov at foss dot arm dot com>
- To: noloader at gmail dot com, "gcc-help at gcc dot gnu dot org" <gcc-help at gcc dot gnu dot org>
- Date: Wed, 11 May 2016 10:18:45 +0100
- Subject: Re: ARM NEON Intrinsics guide?
- Authentication-results: sourceware.org; auth=none
- References: <CAH8yC8mz5pG_TYDCZDtyOdgRW=Ay4fRN-OXduQcAbo12rjRQog at mail dot gmail dot com>
Hi,
On 11/05/16 07:03, Jeffrey Walton wrote:
Hi Everyone,
I'm working on a port of some software to ARM v7, v7-a and v8-a, which
means SIMD coprocessor/NEON is available.
The performance increases when the data types are 32-bit using
int32x4_t vectors, but its not quite what I expected. As a
measurement, Clang produces code near the theoretical throughput, and
its about 2 cycles per byte faster than GCC. But GCC NEON is better
than the C/C++ measurements.
I'm not seeing the performance gain I expected when the data types are
64-bit using int64x2_t vectors. GCC produces code that's nowhere near
Clang or the theoretical limit. In fact, its slower than the C/C++
code.
What does the generated code look like for GCC vs Clang?
Is it just instruction scheduling differences or is there
more register movement, stack spilling etc?
A bug report with a standalone example would be very helpful.
I feel like I'm missing something with respect to using GCC and NEON
intrinsics. For example, maybe there's a technique or pattern to help
GCC minimizes stalls.
For completeness, here are the CFLAGS I am using:
ARMv7:
-DNDEBUG -O3 -march=armv7-a -mfpu=neon
-DNDEBUG -O3 -mcpu=cortex-a7 -mfpu=neon
ARMv8:
-DNDEBUG -O3 -O3 -march=armv8-a+crc -mcpu=cortex-a53
-DNDEBUG -O3 -O3 -march=armv8-a+crc -mcpu=cortex-a53 -mfpu=neon
Is there a GCC guide for NEON intinsics?
As has been mentioned on this thread already,
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0073a/IHI0073A_arm_neon_intrinsics_ref.pdf
is a list of the intrinsics and how they map down to NEON instructions, thought it's
more of a reference rather than a user guide.
If you can isolate a standalone example where GCC NEON intrinsics perform poorly it can you
please file a bug report with the testcase.
As an aside, I notice your command-line options are sub-optimal.
If you're targeting a Cortex-A7 you want to use -mfpu=neon-vfpv4 rather than just -mfpu=neon.
This will give you access to the vfma instructions.
Whereas if you're targeting ARMv8-A on a Cortex-A53 you'll want to use -mfpu=neon-fp-armv8
to enable the ARMv8 floating-point an NEON instructions.
Cheers,
Kyrill