1*09467b48Spatrick============================================== 2*09467b48SpatrickUsing ARM NEON instructions in big endian mode 3*09467b48Spatrick============================================== 4*09467b48Spatrick 5*09467b48Spatrick.. contents:: 6*09467b48Spatrick :local: 7*09467b48Spatrick 8*09467b48SpatrickIntroduction 9*09467b48Spatrick============ 10*09467b48Spatrick 11*09467b48SpatrickGenerating code for big endian ARM processors is for the most part straightforward. NEON loads and stores however have some interesting properties that make code generation decisions less obvious in big endian mode. 12*09467b48Spatrick 13*09467b48SpatrickThe aim of this document is to explain the problem with NEON loads and stores, and the solution that has been implemented in LLVM. 14*09467b48Spatrick 15*09467b48SpatrickIn this document the term "vector" refers to what the ARM ABI calls a "short vector", which is a sequence of items that can fit in a NEON register. This sequence can be 64 or 128 bits in length, and can constitute 8, 16, 32 or 64 bit items. This document refers to A64 instructions throughout, but is almost applicable to the A32/ARMv7 instruction sets also. The ABI format for passing vectors in A32 is sligtly different to A64. Apart from that, the same concepts apply. 16*09467b48Spatrick 17*09467b48SpatrickExample: C-level intrinsics -> assembly 18*09467b48Spatrick--------------------------------------- 19*09467b48Spatrick 20*09467b48SpatrickIt may be helpful first to illustrate how C-level ARM NEON intrinsics are lowered to instructions. 21*09467b48Spatrick 22*09467b48SpatrickThis trivial C function takes a vector of four ints and sets the zero'th lane to the value "42":: 23*09467b48Spatrick 24*09467b48Spatrick #include <arm_neon.h> 25*09467b48Spatrick int32x4_t f(int32x4_t p) { 26*09467b48Spatrick return vsetq_lane_s32(42, p, 0); 27*09467b48Spatrick } 28*09467b48Spatrick 29*09467b48Spatrickarm_neon.h intrinsics generate "generic" IR where possible (that is, normal IR instructions not ``llvm.arm.neon.*`` intrinsic calls). The above generates:: 30*09467b48Spatrick 31*09467b48Spatrick define <4 x i32> @f(<4 x i32> %p) { 32*09467b48Spatrick %vset_lane = insertelement <4 x i32> %p, i32 42, i32 0 33*09467b48Spatrick ret <4 x i32> %vset_lane 34*09467b48Spatrick } 35*09467b48Spatrick 36*09467b48SpatrickWhich then becomes the following trivial assembly:: 37*09467b48Spatrick 38*09467b48Spatrick f: // @f 39*09467b48Spatrick movz w8, #0x2a 40*09467b48Spatrick ins v0.s[0], w8 41*09467b48Spatrick ret 42*09467b48Spatrick 43*09467b48SpatrickProblem 44*09467b48Spatrick======= 45*09467b48Spatrick 46*09467b48SpatrickThe main problem is how vectors are represented in memory and in registers. 47*09467b48Spatrick 48*09467b48SpatrickFirst, a recap. The "endianness" of an item affects its representation in memory only. In a register, a number is just a sequence of bits - 64 bits in the case of AArch64 general purpose registers. Memory, however, is a sequence of addressable units of 8 bits in size. Any number greater than 8 bits must therefore be split up into 8-bit chunks, and endianness describes the order in which these chunks are laid out in memory. 49*09467b48Spatrick 50*09467b48SpatrickA "little endian" layout has the least significant byte first (lowest in memory address). A "big endian" layout has the *most* significant byte first. This means that when loading an item from big endian memory, the lowest 8-bits in memory must go in the most significant 8-bits, and so forth. 51*09467b48Spatrick 52*09467b48Spatrick``LDR`` and ``LD1`` 53*09467b48Spatrick=================== 54*09467b48Spatrick 55*09467b48Spatrick.. figure:: ARM-BE-ldr.png 56*09467b48Spatrick :align: right 57*09467b48Spatrick 58*09467b48Spatrick Big endian vector load using ``LDR``. 59*09467b48Spatrick 60*09467b48Spatrick 61*09467b48SpatrickA vector is a consecutive sequence of items that are operated on simultaneously. To load a 64-bit vector, 64 bits need to be read from memory. In little endian mode, we can do this by just performing a 64-bit load - ``LDR q0, [foo]``. However if we try this in big endian mode, because of the byte swapping the lane indices end up being swapped! The zero'th item as laid out in memory becomes the n'th lane in the vector. 62*09467b48Spatrick 63*09467b48Spatrick.. figure:: ARM-BE-ld1.png 64*09467b48Spatrick :align: right 65*09467b48Spatrick 66*09467b48Spatrick Big endian vector load using ``LD1``. Note that the lanes retain the correct ordering. 67*09467b48Spatrick 68*09467b48Spatrick 69*09467b48SpatrickBecause of this, the instruction ``LD1`` performs a vector load but performs byte swapping not on the entire 64 bits, but on the individual items within the vector. This means that the register content is the same as it would have been on a little endian system. 70*09467b48Spatrick 71*09467b48SpatrickIt may seem that ``LD1`` should suffice to peform vector loads on a big endian machine. However there are pros and cons to the two approaches that make it less than simple which register format to pick. 72*09467b48Spatrick 73*09467b48SpatrickThere are two options: 74*09467b48Spatrick 75*09467b48Spatrick 1. The content of a vector register is the same *as if* it had been loaded with an ``LDR`` instruction. 76*09467b48Spatrick 2. The content of a vector register is the same *as if* it had been loaded with an ``LD1`` instruction. 77*09467b48Spatrick 78*09467b48SpatrickBecause ``LD1 == LDR + REV`` and similarly ``LDR == LD1 + REV`` (on a big endian system), we can simulate either type of load with the other type of load plus a ``REV`` instruction. So we're not deciding which instructions to use, but which format to use (which will then influence which instruction is best to use). 79*09467b48Spatrick 80*09467b48Spatrick.. The 'clearer' container is required to make the following section header come after the floated 81*09467b48Spatrick images above. 82*09467b48Spatrick.. container:: clearer 83*09467b48Spatrick 84*09467b48Spatrick Note that throughout this section we only mention loads. Stores have exactly the same problems as their associated loads, so have been skipped for brevity. 85*09467b48Spatrick 86*09467b48Spatrick 87*09467b48SpatrickConsiderations 88*09467b48Spatrick============== 89*09467b48Spatrick 90*09467b48SpatrickLLVM IR Lane ordering 91*09467b48Spatrick--------------------- 92*09467b48Spatrick 93*09467b48SpatrickLLVM IR has first class vector types. In LLVM IR, the zero'th element of a vector resides at the lowest memory address. The optimizer relies on this property in certain areas, for example when concatenating vectors together. The intention is for arrays and vectors to have identical memory layouts - ``[4 x i8]`` and ``<4 x i8>`` should be represented the same in memory. Without this property there would be many special cases that the optimizer would have to cleverly handle. 94*09467b48Spatrick 95*09467b48SpatrickUse of ``LDR`` would break this lane ordering property. This doesn't preclude the use of ``LDR``, but we would have to do one of two things: 96*09467b48Spatrick 97*09467b48Spatrick 1. Insert a ``REV`` instruction to reverse the lane order after every ``LDR``. 98*09467b48Spatrick 2. Disable all optimizations that rely on lane layout, and for every access to an individual lane (``insertelement``/``extractelement``/``shufflevector``) reverse the lane index. 99*09467b48Spatrick 100*09467b48SpatrickAAPCS 101*09467b48Spatrick----- 102*09467b48Spatrick 103*09467b48SpatrickThe ARM procedure call standard (AAPCS) defines the ABI for passing vectors between functions in registers. It states: 104*09467b48Spatrick 105*09467b48Spatrick When a short vector is transferred between registers and memory it is treated as an opaque object. That is a short vector is stored in memory as if it were stored with a single ``STR`` of the entire register; a short vector is loaded from memory using the corresponding ``LDR`` instruction. On a little-endian system this means that element 0 will always contain the lowest addressed element of a short vector; on a big-endian system element 0 will contain the highest-addressed element of a short vector. 106*09467b48Spatrick 107*09467b48Spatrick -- Procedure Call Standard for the ARM 64-bit Architecture (AArch64), 4.1.2 Short Vectors 108*09467b48Spatrick 109*09467b48SpatrickThe use of ``LDR`` and ``STR`` as the ABI defines has at least one advantage over ``LD1`` and ``ST1``. ``LDR`` and ``STR`` are oblivious to the size of the individual lanes of a vector. ``LD1`` and ``ST1`` are not - the lane size is encoded within them. This is important across an ABI boundary, because it would become necessary to know the lane width the callee expects. Consider the following code: 110*09467b48Spatrick 111*09467b48Spatrick.. code-block:: c 112*09467b48Spatrick 113*09467b48Spatrick <callee.c> 114*09467b48Spatrick void callee(uint32x2_t v) { 115*09467b48Spatrick ... 116*09467b48Spatrick } 117*09467b48Spatrick 118*09467b48Spatrick <caller.c> 119*09467b48Spatrick extern void callee(uint32x2_t); 120*09467b48Spatrick void caller() { 121*09467b48Spatrick callee(...); 122*09467b48Spatrick } 123*09467b48Spatrick 124*09467b48SpatrickIf ``callee`` changed its signature to ``uint16x4_t``, which is equivalent in register content, if we passed as ``LD1`` we'd break this code until ``caller`` was updated and recompiled. 125*09467b48Spatrick 126*09467b48SpatrickThere is an argument that if the signatures of the two functions are different then the behaviour should be undefined. But there may be functions that are agnostic to the lane layout of the vector, and treating the vector as an opaque value (just loading it and storing it) would be impossible without a common format across ABI boundaries. 127*09467b48Spatrick 128*09467b48SpatrickSo to preserve ABI compatibility, we need to use the ``LDR`` lane layout across function calls. 129*09467b48Spatrick 130*09467b48SpatrickAlignment 131*09467b48Spatrick--------- 132*09467b48Spatrick 133*09467b48SpatrickIn strict alignment mode, ``LDR qX`` requires its address to be 128-bit aligned, whereas ``LD1`` only requires it to be as aligned as the lane size. If we canonicalised on using ``LDR``, we'd still need to use ``LD1`` in some places to avoid alignment faults (the result of the ``LD1`` would then need to be reversed with ``REV``). 134*09467b48Spatrick 135*09467b48SpatrickMost operating systems however do not run with alignment faults enabled, so this is often not an issue. 136*09467b48Spatrick 137*09467b48SpatrickSummary 138*09467b48Spatrick------- 139*09467b48Spatrick 140*09467b48SpatrickThe following table summarises the instructions that are required to be emitted for each property mentioned above for each of the two solutions. 141*09467b48Spatrick 142*09467b48Spatrick+-------------------------------+-------------------------------+---------------------+ 143*09467b48Spatrick| | ``LDR`` layout | ``LD1`` layout | 144*09467b48Spatrick+===============================+===============================+=====================+ 145*09467b48Spatrick| Lane ordering | ``LDR + REV`` | ``LD1`` | 146*09467b48Spatrick+-------------------------------+-------------------------------+---------------------+ 147*09467b48Spatrick| AAPCS | ``LDR`` | ``LD1 + REV`` | 148*09467b48Spatrick+-------------------------------+-------------------------------+---------------------+ 149*09467b48Spatrick| Alignment for strict mode | ``LDR`` / ``LD1 + REV`` | ``LD1`` | 150*09467b48Spatrick+-------------------------------+-------------------------------+---------------------+ 151*09467b48Spatrick 152*09467b48SpatrickNeither approach is perfect, and choosing one boils down to choosing the lesser of two evils. The issue with lane ordering, it was decided, would have to change target-agnostic compiler passes and would result in a strange IR in which lane indices were reversed. It was decided that this was worse than the changes that would have to be made to support ``LD1``, so ``LD1`` was chosen as the canonical vector load instruction (and by inference, ``ST1`` for vector stores). 153*09467b48Spatrick 154*09467b48SpatrickImplementation 155*09467b48Spatrick============== 156*09467b48Spatrick 157*09467b48SpatrickThere are 3 parts to the implementation: 158*09467b48Spatrick 159*09467b48Spatrick 1. Predicate ``LDR`` and ``STR`` instructions so that they are never allowed to be selected to generate vector loads and stores. The exception is one-lane vectors [1]_ - these by definition cannot have lane ordering problems so are fine to use ``LDR``/``STR``. 160*09467b48Spatrick 161*09467b48Spatrick 2. Create code generation patterns for bitconverts that create ``REV`` instructions. 162*09467b48Spatrick 163*09467b48Spatrick 3. Make sure appropriate bitconverts are created so that vector values get passed over call boundaries as 1-element vectors (which is the same as if they were loaded with ``LDR``). 164*09467b48Spatrick 165*09467b48SpatrickBitconverts 166*09467b48Spatrick----------- 167*09467b48Spatrick 168*09467b48Spatrick.. image:: ARM-BE-bitcastfail.png 169*09467b48Spatrick :align: right 170*09467b48Spatrick 171*09467b48SpatrickThe main problem with the ``LD1`` solution is dealing with bitconverts (or bitcasts, or reinterpret casts). These are pseudo instructions that only change the compiler's interpretation of data, not the underlying data itself. A requirement is that if data is loaded and then saved again (called a "round trip"), the memory contents should be the same after the store as before the load. If a vector is loaded and is then bitconverted to a different vector type before storing, the round trip will currently be broken. 172*09467b48Spatrick 173*09467b48SpatrickTake for example this code sequence:: 174*09467b48Spatrick 175*09467b48Spatrick %0 = load <4 x i32> %x 176*09467b48Spatrick %1 = bitcast <4 x i32> %0 to <2 x i64> 177*09467b48Spatrick store <2 x i64> %1, <2 x i64>* %y 178*09467b48Spatrick 179*09467b48SpatrickThis would produce a code sequence such as that in the figure on the right. The mismatched ``LD1`` and ``ST1`` cause the stored data to differ from the loaded data. 180*09467b48Spatrick 181*09467b48Spatrick.. container:: clearer 182*09467b48Spatrick 183*09467b48Spatrick When we see a bitcast from type ``X`` to type ``Y``, what we need to do is to change the in-register representation of the data to be *as if* it had just been loaded by a ``LD1`` of type ``Y``. 184*09467b48Spatrick 185*09467b48Spatrick.. image:: ARM-BE-bitcastsuccess.png 186*09467b48Spatrick :align: right 187*09467b48Spatrick 188*09467b48SpatrickConceptually this is simple - we can insert a ``REV`` undoing the ``LD1`` of type ``X`` (converting the in-register representation to the same as if it had been loaded by ``LDR``) and then insert another ``REV`` to change the representation to be as if it had been loaded by an ``LD1`` of type ``Y``. 189*09467b48Spatrick 190*09467b48SpatrickFor the previous example, this would be:: 191*09467b48Spatrick 192*09467b48Spatrick LD1 v0.4s, [x] 193*09467b48Spatrick 194*09467b48Spatrick REV64 v0.4s, v0.4s // There is no REV128 instruction, so it must be synthesizedcd 195*09467b48Spatrick EXT v0.16b, v0.16b, v0.16b, #8 // with a REV64 then an EXT to swap the two 64-bit elements. 196*09467b48Spatrick 197*09467b48Spatrick REV64 v0.2d, v0.2d 198*09467b48Spatrick EXT v0.16b, v0.16b, v0.16b, #8 199*09467b48Spatrick 200*09467b48Spatrick ST1 v0.2d, [y] 201*09467b48Spatrick 202*09467b48SpatrickIt turns out that these ``REV`` pairs can, in almost all cases, be squashed together into a single ``REV``. For the example above, a ``REV128 4s`` + ``REV128 2d`` is actually a ``REV64 4s``, as shown in the figure on the right. 203*09467b48Spatrick 204*09467b48Spatrick.. [1] One lane vectors may seem useless as a concept but they serve to distinguish between values held in general purpose registers and values held in NEON/VFP registers. For example, an ``i64`` would live in an ``x`` register, but ``<1 x i64>`` would live in a ``d`` register. 205*09467b48Spatrick 206