1

Using your C compiler to exploit

NEON™ Advanced SIMD

Copyright ©2010, Doulos, All rights reserved

http://www.doulos.com/arm/

Marcus Harnisch <marcus.harnisch@doulos.com>

Abstract

compilers use a blend of sophisticated analysis techniques and language extensions to fulfill their

job.

Introduction

Many algorithms in today’s multi-media addicted world are ideally suited for vector operations

including digital filtering (audio), pixel processing (video), matrix operations (3D, DCT). Some lesser

known applications might perhaps include automation (drives, robotics).

Most vector operations carry out the same operation on all elements of their operand vector(s) in

parallel (Figure 1), hence the term Single Instruction Multiple Data (SIMD) which has its roots in a

computer architecture classification system called “Flynn’s Taxonomy”.

1

1

Flynn, M., Some Computer Organizations and Their Effectiveness, IEEE Trans. Comput., Vol. C-21, pp. 948,

1972.

performance boost. But t

while

(Figure 2). This flavor of a

Since vectors in v6 SIMD are

vector size of only 32 bits, i.e.

With some rather well designed

2

2

started including SIMD in some

still in the

set is executed in

four (eight bit

two-

-559

s anyhow,

early mobile

and was

Using your C compiler to exploit NEON™ Advanced SIMD

3

single data word. With the availability of these instructions in the just announced Cortex-M4

Currently ARMv6 SIMD instructions won’t be generated automatically by the RealView C compiler.

These instructions are accessible via assembler language and compiler intrinsics only.

With multimedia content becoming ubiquitous even in the power-sensitive market for mobile

devices, the introduction of a comprehensive set of SIMD operations became essential to

maintaining a leading position in the embedded processor market.

With architecture v7-A, application processors (all members of the ARM Cortex-A family) got the

option to implement a SIMD instruction set which ARM trademarked “NEON”. Compatible cores

from other vendors will use different names (e.g. VeNum in Qualcomm’s Scorpion core) although it

is rather likely that NEON will become a synonym for the generic term “Advanced SIMD”.

The NEON instruction set is well defined and relatively easy to understand. Developers familiar with

the ARM instruction sets will be able to write NEON code without too much effort. ARM has

structured the instruction syntax according to different data types, result behavior, etc. The

challenge is rather in memorizing which combinations are available for each base instruction.

With Advanced SIMD being executed inside the processor core, it has several benefits over a

dedicated DSP:

• Only one compiler for code generation needed

• Instruction set common for all NEON implementations

• Same instruction stream and flow control as rest of application

• No configuration necessary (other than enabling)

which a DSP could operate largely independently of the main CPU, having a silicon side-kick could

give a significant performance advantage.

Using your C compiler to exploit NEON™ Advanced SIMD

4

NEON Architecture

NEON is integrated into the ARM core as a coprocessor. Since NEON shares registers with the vector

floating point unit (VFP), the latter will always be present in cores with Advanced SIMD extensions.

NEON stores operands and results in a set of 16 quad-word registers (q0—q15), that can be used

alternatively as 32 double-word registers (d0—d31). Values can be moved between NEON registers

and core registers (r0—r15), as well as between memory and NEON registers. Data types supported

by NEON are vectors of 8, 16, 32, and 64 bit integer, as well as single precision (32 bit) floating point

Using your C compiler to exploit NEON™ Advanced SIMD

5

When assembler programming is considered, it is important to understand that the ARM

3

Same is true, of course, for assembler programs. But these guys usually remember those little details.

Using your C compiler to exploit NEON™ Advanced SIMD

6

and generic at the same time, as intrinsics will be translated to according assembler instructions

just single accumulator (

result

), we could have four of them, one in each “vector lane”. After

exiting the inner loop, all accumulators will be added to form the result, which will be written out to

memory again. An intermediate representation of this idea is shown in Figure 7.

4

There are other intrinsics, too. See the C Compiler Reference Manual for details.

5

You really don’t want to see their definitions. If you do, you’ll find them in arm_neon.h.

6

ARM Architecture Procedure Call Standard, ARM IHI0042D, Appendix A.2

void fir_neon(const int16_t *s, const int16_t *c,

int32_t *y, const uint32_t num_samples)

{

uint32_t i, j;

result += c[j] * s[i+j];

}

y[i] = result;

}

}

int32x4_t // vector of four 32bit elements

uint16x8_t // vector of eight 16bit elements

int8x8x2_t // array of two vectors with eight 8 bit elements

Using your C compiler to exploit NEON™ Advanced SIMD

7

You will have noticed that this implementation requires

num_samples

to be divisible by four. This

Let us try now to translate this into NEON intrinsics. First, the header file arm_neon.h has to be

included to define all vector data types and intrinsics. The array

will have to be turned into a

real vector type. Since we want to process four samples at a time, the type

int32x4_t

(vector of

four 32 bit signed integer values) would be appropriate. Note that we cannot directly access source

and coefficient data in memory as in the two previous examples. We will have to define two vectors

each holding four samples. Since source data and coefficients are represented by 16 bit integers, we

will declare

si

ci

. For loading data into a vector, we’ll have to use intrinsics. In

this case a vld1_s16() will do, where the s16 part indicates that the data type of vector elements

would a signed 16 bit integer.

int32_t o[4];

for (i = 0; i < num_samples; i++) {

o[0] = o[1] = o[2] = o[3] = 0;

for (j = 0; j < 64; j+=4) {

o[0] += c[j+0] * s[i+j+0];

o[1] += c[j+1] * s[i+j+1];

o[2] += c[j+2] * s[i+j+2];

#include <arm_neon.h>

void fir_neon(const int16_t *s, const int16_t *c,

int32_t *y, const uint32_t num_samples)

{

uint32_t i, j;

int16x4_t si, ci;

int32x4_t o;

for (i = 0; i < num_samples; i++) {

o = vdupq_n_s32(0);

+ vgetq_lane_s32(o, 1)

+ vgetq_lane_s32(o, 2)

+ vgetq_lane_s32(o, 3);

}

}

Using your C compiler to exploit NEON™ Advanced SIMD

8

After loading both, coefficients and samples vectors, we can now multiply/accumulate

si

The compiler won’t optimize your code when it sees intrinsics. It will slavishly translate your

commands in the same order as you wrote them. Using C statements, the unsuspecting developer

might believe that detailed knowledge of the NEON instruction set wasn’t needed. However, NEON

side effects and thus won’t optimize the loop. Since we are using variables instead to hold vectors,

the intrinsics approach also hides the register allocation. It is rather easy this way to exceed the

between ARM core registers and NEON registers might not be obvious at the C source code level.

Instruction scheduling by the compiler is not affected by the specified processor type it seems.

To summarize: NEON intrinsics give you access to the Advanced SIMD instruction set, but are hardly

easier to use than writing assembler language to begin with (in some cases worse actually) and just

like assembler, they require NEON architecture and instruction set knowledge. Their main advantage

is the fact that NEON intrinsics can be inlined with other C statements.

addition in ARM core

registers

VLD1.16 {d3},[r6]

ADD r6,r1,r12,LSL #1

ADD r12,r12,#4

VLD1.16 {d2},[r6]

CMP r12,#0x40

VMLAL.S16 q0,d3,d2

BCC |L1.300|

VMOV.32 r12,d0[0]

VMOV.32 r4,d0[1]

ADD r12,r12,r4

VMOV.32 r4,d1[0]

ADD r12,r12,r4

Using your C compiler to exploit NEON™ Advanced SIMD

9

The exact impact of scheduling instructions in a certain way becomes harder to grasp with every new

compilers is to throw arbitrary high-level code at the compiler and it will make best use of all

available processor resources. This is the fundamental task of a compiler already, so why shouldn’t

Alternatively GCC supports this, too.

The compiler will analyze your code and find out whether certain loops could be mapped to a vector

algorithm. In that sense, vectorization is closely related to loop optimization. RVCT enables loop

transformation and vectorization only if highest optimization levels are chosen and the optimization

goal is execution time.

Going back to our original FIR filter example (Figure 6), we now enable the RVCT auto-vectorizer with

these command line options:

armcc --cpu=Cortex-A9 -O3 -Otime --vectorize --remarks -c fir_neon.c

only that, the compiler seemed to have transformed the loop structure. Let’s see for ourselves:

|L1.80|

VLD1.16 {d4},[r1]!

SUBS r7,r7,#1

VLD1.16 {d21},[r1]!

VLD1.16 {d18},[r12]!

VMLAL.S16 q0,d4,d18