SIMD on Tom's Lab Notes

SIMD Algorithm Design: Beyond Basic Vectorization

Wed, 17 Sep 2025 00:00:00 +0000

In this post I will improve the performance of an algorithm that converts RGB888 images to RGB565. It is divided into different sections:

First, I will give a brief introduction on RGB888 RGB565 and converting between the two, and present a scalar algorithm that achieves this task.
Next, I will use SIMD Neon instructions to attempt to manually ‘optimize’ this algorithm. I will also introduce an optimized version that uses special SIMD instructions and a slightly different approach to improve the theoretical throughput of the algorithm even further.
Finally, I will present the benchmarking results and compare different versions against each other.
The post will end with a conclusion and a couple of final words.

Any benchmarks are conducted on a MacBook with an M3 Pro CPU with 10 cores, though the code is single threaded. Code is compiled in C23 mode with -O3 (unless stated otherwise).

Benchmarks are ran on 200x200 RGB888 images since I had those on hand from a different project. Note that the performance difference will be marginal in absolute numbers. Partially because of the performant underlying hardware and partially because of the image size of course.

Any performance improvements are to be seen relatively to what they are compared to, since these conclusions similarly apply to bigger problems where the timescale might not be in the $\mu$s range.

Introduction

What is SIMD?

‘Single Instruction Multiple Data’ (SIMD) can be used to improve the performance of algorithms that require the same transformations on a wide range of data. This is achieved by increasing data throughput for every instruction (operating on up to 512 bit ‘vectors’ instead of traditional 64 bit registers).

Transforming RGB888 to RGB565

Transforming 24 bit RGB (8 bits per color channel) into 16 bit RGB effectively means cramming the information contained in 8 bits into 5 or 6 bits and then putting these pixels into a 16 bit value.

There are different approaches to achieve this. The first and most simple one is to just truncate the last 2 or 3 bits.

Taking 3 bit truncation as an example, values would be mapped as follows:

0-7 -> 0
8-15 -> 1
16-23 -> 2
…

When truncating 2 bits 0-3 are mapped to 0, 4-7 that are mapped to 1, and so on.

This is efficient, especially when using SIMD instructions and even has an example in the ‘Coding for Neon’ guide ¹. However, it introduces a bias. It would be better if there was a way to map 4-11 to 1 instead of 8-15, which would be similar ‘rounding’.

This is possible due to offsets, so before shifting by 3 (dividing by 8), half of that is added (+4). This results in:

0-3 -> 0
4-11 -> 1
12-17 -> 2
…

A scalar version of this algorithm could look like this:

 1void rgb888_to_rgb565_scalar(Image *src, Image *dst) {
 2
 3 for (int i = 0; i < src->img_width * src->img_height; i++) {
 4 // retrieve RGB 888 values
 5 uint8_t r = src->buffer[i * 3 + 0];
 6 uint8_t g = src->buffer[i * 3 + 1];
 7 uint8_t b = src->buffer[i * 3 + 2];
 8
 9 // add half the lost precision before truncating
10 uint16_t r5 = (r + 4) >> 3; // +4 is half of 8 (2^3)
11 uint16_t g6 = (g + 2) >> 2; // +2 is half of 4 (2^2)
12 uint16_t b5 = (b + 4) >> 3; // +4 is half of 8 (2^3)
13
14 // clamp to prevent overflow
15 if (r5 > 31)
16 r5 = 31;
17 if (g6 > 63)
18 g6 = 63;
19 if (b5 > 31)
20 b5 = 31;
21
22 // packing 16 bit value
23 uint16_t value = (uint16_t)((r5 << 11) | (g6 << 5) | b5);
24
25 // save RGB 565 values
26 ((uint16_t *)dst->buffer)[i] = value;
27 }
28}

Vectorizing

SIMD on Arm is implemented by the Neon architecture extension. The register width is 128 bits, which is pretty small when compared to different SIMD extensions on x86, such as 512 bits on AVX 512 or 256 bits on AVX2. So the maximum number of values that would fit in a Neon register are 16 8 bit values.

I have used the intrinsics provided by the neon.h header file, as opposed to inline assembly. The instructions will be the same, but the code is much more readable and easier to write. The corresponding type provided by the Neon header file for our 16 8 bit values data type would be uint8x16_t. One more type that will be very useful is uint8x16x3_t, representing 3 uint8x16_ts, which is perfect for dealing with color channels.

Naive Approach

Vectorizing this algorithm is very easy, since pixels are stored consecutively in a RGBRGBRGB pattern.

However, there is one problem: The scalar algorithm does any arithmetic operations on 16 bit values, due to the chance of overflows. So while it is possible to load 16 pixels using one instruction and packing 16 color values into one register, the actual processing has to be done one 16-bit integers, which limits the number of color values per register to 8.

So that means one of two things for the vectorized version:

Only load 3x8 values, since that is the max numbers that can be processed with one instruction. I will refer to this approach as ‘8P’ moving forward.
Load 3x16 values, but separate the color values into 2 registers per channel before doing arithmetic operations. I will refer to this approach as ‘16P’ in the future.

The number of arithmetic instruction required to process the data is the same for both approaches. The second approach (16P) will process 16 pixels per iteration, but requires twice the add, shift and or instructions. However, processing 16 pixels per iteration reduces the required load instructions by half, and the same actually applies to stores as we will see later. Though this comes at the cost of a higher register usage.

This is also reflected in the generated assembly.

Particularly interesting are the parts inside the for-loop. The first 2 instructions (locations 100001e58 & 100001e5c in the 8P implementation) load the source and compute the offset to load the pixels to be processed into the correct registers. The algorithm really starts ld3.8b { v4, v5, v6 }, [x11] at 100001e60 loading the pixels into SIMD registers. 16P uses the ld3.16b { v4, v5, v6 }, [x11] instruction instead (from location 100001f30) As you can see they are almost identical, the only difference is in the operand suffix (16b vs 8b). The number indicates the number of values that are loaded, and the letter describes the data type. In this case 16 bytes and 8 bytes respectively². The rest is exactly the same except that 16P executes every arithmetic instruction twice (once on the upper and once on the lower half of course) and uses more registers.

Below is a brief explanation of the entire generated assembly for the loop body. The full assembly can be found in the Appendix.

 1100001e58: f940000b ldr x11, [x0] ; load source buffer
 2100001e5c: 8b08016b add x11, x11, x8 ; compute current location offset
 3100001e60: 0c404164 ld3.8b { v4, v5, v6 }, [x11] ; load pixels
 4100001e64: 2e241007 uaddw.8h v7, v0, v4 ; add 4 to red
 5100001e68: 2e251030 uaddw.8h v16, v1, v5 ; add 2 to green
 6100001e6c: 6f1d04e7 ushr.8h v7, v7, #0x3 ; shift red
 7100001e70: 6f1e0610 ushr.8h v16, v16, #0x2 ; shift green
 8100001e74: 2e261004 uaddw.8h v4, v0, v6 ; add 4 to blue
 9100001e78: 6f1d0484 ushr.8h v4, v4, #0x3 ; shift blue
10100001e7c: 6e626ce5 umin.8h v5, v7, v2 ; clamp red
11100001e80: 6e636e06 umin.8h v6, v16, v3 ; clamp green
12100001e84: 4f1b54a5 shl.8h v5, v5, #0xb ; shift red to its location in the 16 bit buffer
13100001e88: 4f1554c6 shl.8h v6, v6, #0x5 ; shift green to its location in the 16 bit buffer
14100001e8c: 6e626c84 umin.8h v4, v4, v2 ; clamp blue
15100001e90: 4ea51cc5 orr.16b v5, v6, v5 ; or red and green together
16100001e94: 4ea41ca4 orr.16b v4, v5, v4 ; or blue with red & green
17100001e98: f940002b ldr x11, [x1] ; load destination base pointer
18100001e9c: 3ca96964 str q4, [x11, x9] ; write result back to buffer
19100001ea0: 9100214a add x10, x10, #0x8 ; i += 8
20100001ea4: a941300b ldp x11, x12, [x0, #0x10] ; load loop bound values
21100001ea8: 9b0b7d8b mul x11, x12, x11 ; compute total/limit
22100001eac: 91004129 add x9, x9, #0x10 ; advance output pointer (16 bytes)
23100001eb0: 91006108 add x8, x8, #0x18 ; advance input pointer (24 bytes)
24100001eb4: eb0a017f cmp x11, x10 ; check for condition
25100001eb8: 54fffd08 b.hi 0x100001914 <_rgb888_to_rgb565_neon_8vals+0x54> ; branch based on comparison result

This totals 25 instructions from load to branch, resulting in 3.125 instructions per pixel. The same routine, when processing 16 pixels per iteration (from location 100001f28 to 100001fc8, see Appendix), takes 41 instructions, resulting in 2.5625 instructions per pixel.

So all else being equal it is expected that 16P is a little faster, at least assuming there is no cost associated with the extra register usage. Note that that might not always be the case, especially with high memory pressure. However, the benchmarks are conducted with enough free RAM and low memory pressure to reduce influences by outside, non-related causes.

Optimized Algorithm

However, 16P has one fundamental flaw:

It does not truly increase the throughput by 16x.

While 8P actually processed 8 pixels with a similar amount of instructions, 16P only loads and stores 16 pixels at once. For processing, the pixels are split into two 8 value registers, since the processing is fundamentally done on 16 bit values, so it is technically not possible to do arithmetic operations on 16 values at once, due the register sizes of 128 bits.

To actually process 16 pixels, at least through most of the iteration, the algorithm has to be slightly changed, so that more arithmetic operations can be done on 8 bit values. And there is a way, that allows for processing 16 pixels for most of the algorithm, only splitting and moving them into registers holding 16bit values when combining the 3 color channels to RGB565.

Fundamentally, instead of clamping the values after adding and shifting, an overflow detection could be implemented that then sets the value to 255 if it overflowed. This will result to the correct maximum of 31 & 64 respectively after shifting.

Scalar pseudocode would look like this:

 1void rgb888_to_rgb565_neon(Image *src, Image *dst) {
 2 for (int i = 0; i < src->img_width * src->img_height; i++) {
 3
 4 uint8_t r = src->buffer[i * 3 + 0];
 5 // same for green & blue just like before
 6
 7 uint8_t r5 = r + 4;
 8 // +2 for green & +4 for blue, just like before
 9
10 if (r5 < r)
11 r5 = 255;
12 // same for green & blue
13
14 r5 = r5 >> 3;
15 // shift green & blue like before
16
17 uint16_t value = (uint16_t)((r5 << 11) | (g6 << 5) | b5);
18
19 ((uint16_t *)dst->buffer)[i] = value;
20 }
21}

A naive vectorization of the comparison operation of this version would be more complicated though. The clamping in the original algorithm is essentially just a min between the actual value and the max value. When using Neon the vminq_u16 intrinsic can be used for this.

Reimplementing logic like that in Neon requires the comparison using vcgtq_u8, creating a mask, followed by vbslq_u8, which uses the mask to either set the current value or 255. The full implementation of this implementation can be found in the Appendix.

However, there is a way to avoid the comparison and masking through the use of ‘saturating arithmetic’. A ‘saturation add’ will perform a pairwise addition as usual, but it will cap the result at the maximum value (255 for 8 bit values). Which is exactly what is needed here. The intrinsic for this operation is vqaddq_u8. This implementation can also be found in the Appendix. Using ‘saturation math’ is not only simpler to implement but also expected to provide an even more substantial performance improvement, since it reduces the number of required instructions compared to the masking approach.

Throughout this post, I will use ‘Optimized Algorithm’ (or ‘OA’) to refer to algorithm as a whole. If it is necessary to distinguish between both implementations, ‘OA’ will refer to the one using masks and ‘SA’ or ‘Saturation Add’ will refer to the one using the ‘saturation add’ operation.

Benchmarks

First I will give brief introduction on the benchmarking & data collection settings and environment. This is followed by a concise analysis of the collected data. Finally, I will go over the different results comparing different implementations and finish this section with a brief subsection about limitations.

The purpose of these benchmarks are to answer the following questions:

When vectorizing the original algorithm, is the extra register usage of processing 16 pixels per iteration better than processing 8 pixels per iteration?
Can the compiler automatically vectorize the algorithm? How would the compiler generated version compare to the hand vectorized version?
How does the improved algorithm compare against the compiler generated version?
What is the difference does the use of the ‘saturation add’ make?
What is the baseline speed (scalar) and how do the different versions compare against baseline but also against each other?

Benchmark settings

The parameters under which the benchmarks were ran are as follows:

Benchmarks are executed on 2682 RGB888 images with 200x200 pixels.
The benchmark runs every function on every image.
There are always 5 warm-up runs before the timed runs.
There are 20 timed runs and the median is selected as the particular result for that function & image combination.
Output buffers are reused but set to 0 after every run.
Every image runs in its own process to avoid crashes in case of invalid inputs, but they are running sequentially.
I am running the benchmarks on a MacBook M3 Pro (no power saving mode).
setpriority is used to increase the processes priority and thereby reduce interference by other processes.

Data Analysis

Figure 1.1 shows the collected data. There are some significant outliers, due to a variety of possibilities. On macOS it’s unfortunately not possible to pin processes to a specific CPU, so those could be due to context switches. They could also possibly be due to interrupts from the operating system. Unfortunately it appears that it is not possible to set scheduling settings such as SCHED_FIFO on Linux either.

I have tried to minimize outside influences and reduce memory pressure by closing unimportant programs such as browsers or any other user programs that would be running on my machine. But I don’t have a specific benchmarking machine set up just for benchmarks, so they were ran on my personal laptop, so there still are likely suboptimal conditions influencing the benchmark.

To try to get as reliable results as possible, I have set the priority/niceness using setpriority (which obsoletes nice³). I also set the QoS settings to the highest priority to try and keep the benchmark on a P-Core⁴.

 1// set priority
 2if (setpriority(PRIO_PROCESS, 0, -20) == -1) {
 3 perror("setpriority failed - try running as root");
 4 return 1;
 5}
 6
 7// Set QoS to user-interactive to encourage P-core scheduling
 8if (pthread_set_qos_class_self_np(QOS_CLASS_USER_INTERACTIVE, 0) != 0) {
 9 perror("pthread_set_qos_class_self_np failed");
10 return 1;
11}

Collected Data

Collected Data Cleaned

Since I didn’t want to distort the data, I took a reliable but conservative approach to removing outliers. For each function, I replaced any values above the 80^(th) percentile or below the 20^(th) percentile with the median. The corrected distributions are displayed in Figure 1.2

Baseline

First it is important to establish a baseline that any optimization is compared against. For this a truly scalar implementation is used. To achieve this, -O3 optimizations were enabled during compilation (same as every other function). However, to make sure the compiler does not vectorize the algorithm, 2 pragmas were used:

#pragma clang loop vectorize(disable) and #pragma clang loop interleave(disable).

Mean execution time for this configuration is 27031ns.

8 vs 16 pixels per iteration

Boxplot comparison between 8 & 16 pixels per iteration

ECDF comparing 8 & 16 pixels per iteration

While both approaches achieve an equal median performance, processing 16 pixels per iteration shows better consistency, and a slightly higher mean performance, as displayed in the ECDF. The Boxplot also suggests that the worst case execution time of 16P appears to be an outlier, which could be due to other factors such as context switches or CPU frequency scaling, as the boxplot is very flat at a consistent 5000ns. 8P, on the other hand shows equal performance to 16P on the lower and medium quatiles, but starts to diverge at the higher quartiles.

I’ve determined that 16P outperforms 8P slightly, given that 8P’s performance is more variable and has a marginally, but significant, higher mean.

So to answer the question:

When vectorizing the original algorithm, is the extra register usage of processing 16 pixels per iteration better than processing 8 pixels per iteration?

Yes, given the benchmarking parameters, 16P outperforms 8P. Though not by much.

Auto Vectorization

In this section I will look into the optimizations that the compiler made to scalar algorithm, to answer the questions:

Can the compiler automatically vectorize the scalar implementation?
How does it perform compared to other implementations?

Analysis

The full assembly can be found in the Appendix, but I will give a brief overview here:

The compiler actually generated 3 different paths:

A truly scalar version (similar to the one would be generated if you disable the vectorization optimizations).
A version that processes 8 pixels per iteration (similar to what I wrote by hand).
A version that processes 16 pixels per iteration (similar to what I wrote by hand).

So yes, the compiler can automatically vectorize this algorithm/implementation.

I will refer to this as ‘CGV’ (‘Compiler Generated Version’) moving forward.

I did a full deep dive on the difference between the assembly generated from the 16P and the CGV in this post here, going over the generated assembly line by line with explanations as to why the compiler might have generated those particular instructions. But the main difference came from the way values were written back to memory at the end of each iteration.

In the CGV, this is done by a single instruction:

110000171c: ac8115a4 stp q4, q5, [x13], #0x20

The stp instruction takes two SIMD vectors and stores them to a specific address plus a given offset, basically vectorizing the ‘store’. The store sequence for the version that I vectorized were a little more complex and less efficient.

Below you can see the 5 instructions, that the compiler generated. They load the store address from memory twice and then individually store the data to the respective offset:

‘$2 \cdot i$’, as i counts number of pixels, each pixel being 2 bytes, and
‘$2 \cdot i + 16$’, for the second set of 8 pixels, again, each pixel being 2 bytes.

1100001f98: f940002b ldr x11, [x1] ; load store address (dst->buffer) from memory
2; ... remaining scheduled SIMD instruction
3100001fa0: 3ca96964 str q4, [x11, x9] ; store q4 to base + (2 * i)
4100001fa4: f940002b ldr x11, [x1] ; load store address (dst->buffer) from memory
5100001fa8: 8b09016b add x11, x11, x9 ; x11 = 2 * i
6100001fac: 3d800565 str q5, [x11, #0x10] ; store q5 to (2 * i) + 16

Results

As one can see in the benchmark results of the CGV and 16P versions below, they perform almost the same. The difference is actually slightly larger if the benchmarks are ran with a ’niceness’ of 0, then the CGV slightly, but measurably outperforms 16P. However, there is no real difference with a ’niceness’ of -20.

Adjusting the code, so the compiler also generates a stp instruction for my manually vectorized version also closes the gap with a ’niceness’ of 0.

So in the end, the compiler generated the same SIMD instructions, but it could generate slightly better assembly around that. Again, in a different post I use this example to try and figure out why that is.

Optimized Algorithm

Since the CGV and 16P versions are essentially equal, it is expected that the Optimized Algorithm outperforms them both, since it essentially doubles throughput for at least part of the arithmetic. The figure below displays this performance improvement of 6.46 times higher compared to scalar baseline (as opposed to 5.44x from CGV).

Saturation Add

The usage of the saturation add widens this difference even further, resulting in an 8.49x improvement compared to baseline. The corresponding ECDF illustrates this very clearly, outperforming even the original OA by 1/4.

Summary

An 8.5x speedup to a truly scalar version can be achieved by using vectorization. However, modern compilers are able to achieve very good results as well, and the only way to really beat it (in this instance) was to make bigger algorithmic changes, that a compiler would not do. It is not clear how well this applies to algorithms that are less trivial to optimize though.

There also is a stark drop-off in performance improvement when moving from processing 8 pixels per iteration to 16, until the Optimized Algorithm (with ‘saturation add’) caused a significant jump by enabling the higher throughput, with a similar amount of operations. A curve about the speedup trend can be found below the table.

Implementation	Mean (ns)	90th Percentile (ns)	Relative Speedup
scalar (no auto vectorization)	27149.33	29000.0	1.00
CGV	4994.22	5000.0	5.44
8 pixels	5252.42	6000.0	5.17
16 pixels	4999.81	5000.0	5.42
Optimized Algorithm	4203.58	5000.0	6.46
OA with Saturation Add	3199.48	4000.0	8.49

Limitations

I wanted to use pthread_set_qos_class_self_np as well but macOS does not allow this when forking processes. It can be done when using posix_spawn instead, might do that in the future to see if it makes a difference.

After all, setpriority makes a huge difference, not only on the performance numbers themselves, but also on the consistency, and thereby the distributions as a whole. I had collected data without setting the priority/nice value, and those results do look different.

While I have reduced the amount of programs running in the background to keep memory pressure low, there is no way completely control the caches or different processes. MacOS also doesn’t have any real time or priority scheduling, or CPU pinning, so there will be some influence due to interrupts/context switches.

It might be interesting running the same benchmarks on a dedicated benchmarking machine with more control over the operating system. I might try this in the future using a Raspberry Pi.

Conclusions

1. Modern Compilers are pretty good

Modern compilers are very capable at vectorizing code themselves. At least for easily optimizable problems. Manual ‘optimizations’ might actually keep the compiler from some improvements in other areas, so it might not only be not worth it, but also hurting.

However, it might be worth it when vectorization allows you to make structural improvements to the algorithm, that a compiler would not be able to do (as in the case of the ‘Optimized Algorithm’). But ‘dumb vectorization’ is probably better left to the compiler. And if not it should be accompanied by incremental benchmarks.

2. Images are rather small

The performance differences are of course in the scale of microseconds, so the differences/improvements will likely go unnoticed. This is partially due to the relatively low number of iterations, due to the limited image size: $$ \frac{200 \cdot 200 \text{ pixels}}{16 \text{ pixels/iteration}} = \frac{40 000 \text{ pixels}}{16 \text{ pixels/iteration}} = 2 500 \text{ iterations}$$

For bigger image sizes or applications that process more data in general (such as processing point clouds), the difference can be noticeable.

3. It’s really important to know the platform specific instructions/intrinsics

The implementation process of the optimized algorithm shows how important it is to know the instructions of the platform the algorithm is implemented for. Without using the saturation additions for example, the optimized version would only be ~19% faster than the compiler generated version of the original algorithm. As opposed to the ~56% speedup one would gain using the more optimal instructions.

4. Real world vs theoretical performance

The theoretical performance gain for an 8P like implementation would be 8x relative to baseline. The actual result is ~5x, which is significant, but not close to the theoretical limit. The theoretical performance gain overall could be considered to be 16x, since 16 8bit values fit into one 128 bit register. However, naive optimizations (by the compiler or by hand) does not necessarily bring you there. Furthermore, I was not able to achieve this level of throughput throughout the whole loop body.

So in reality, there is a:

16x speedup for the loads
16x speedup for the first addition incl. saturation
16x speedup for the shift right

After that, green and red are split into upper and lower halfs, adding some penalty there, followed by:

8x speedup in red and green shift
8x speedup oring the values together

Finally, if a stp instruction is emitted by the compiler, then there is a 16x speedup in the store. Else it’s 8x.

It is hard to put an exact number on what the expected speedup should be, however assuming the 16x and 8x parts make up 50% each, then a $\frac{8 + 16}{2} = 12x$ theoretical improvement could be expected. Though that might not necessarily be accurate since memory access tends to be particularly slow.

Either way, the final performance peak was ~8.5x, which shows, that there can be a significant gap between expected/theoretical and actual performance.

While there may be additional improvements possible through smarter register management, 8.5x is as good as I can get it at this time. I might revisit this in the future to see if I can figure out a way to do better.

Appendix

Processing 8 pixels per iteration (8P)

 1void rgb888_to_rgb565_neon_8vals(Image *src, Image *dst) {
 2
 3 const uint16x8_t v_4 = vdupq_n_u16(4);
 4 const uint16x8_t v_2 = vdupq_n_u16(2);
 5 const uint16x8_t v_31 = vdupq_n_u16(31);
 6 const uint16x8_t v_63 = vdupq_n_u16(63);
 7
 8 uint8x8x3_t v_rgb888;
 9 uint16x8_t v_rgb565;
10
11 for (int i = 0; i < src->img_width * src->img_height; i += 8) {
12
13 v_rgb888 = vld3_u8(src->buffer + (i * 3));
14
15 uint16x8_t v_r = vmovl_u8(v_rgb888.val[0]);
16 uint16x8_t v_g = vmovl_u8(v_rgb888.val[1]);
17 uint16x8_t v_b = vmovl_u8(v_rgb888.val[2]);
18
19 v_r = vaddq_u16(v_r, v_4);
20 v_g = vaddq_u16(v_g, v_2);
21 v_b = vaddq_u16(v_b, v_4);
22
23 v_r = vshrq_n_u16(v_r, 3);
24 v_g = vshrq_n_u16(v_g, 2);
25 v_b = vshrq_n_u16(v_b, 3);
26
27 v_r = vminq_u16(v_r, v_31);
28 v_g = vminq_u16(v_g, v_63);
29 v_b = vminq_u16(v_b, v_31);
30
31 v_r = vshlq_n_u16(v_r, 11);
32 v_g = vshlq_n_u16(v_g, 5);
33
34 v_rgb565 = vorrq_u16(v_r, v_g);
35 v_rgb565 = vorrq_u16(v_rgb565, v_b);
36
37 vst1q_u16((uint16_t *)dst->buffer + i, v_rgb565);
38 }
39}

 10000000100001e04 <_rgb888_to_rgb565_neon_8vals>:
 2100001e04: a9bf7bfd stp x29, x30, [sp, #-0x10]!
 3100001e08: 910003fd mov x29, sp
 4100001e0c: f9400808 ldr x8, [x0, #0x10]
 5100001e10: f103211f cmp x8, #0xc8
 6100001e14: 54000581 b.ne 0x100001ec4 <_rgb888_to_rgb565_neon_8vals+0xc0>
 7100001e18: f9400c08 ldr x8, [x0, #0x18]
 8100001e1c: f103211f cmp x8, #0xc8
 9100001e20: 54000541 b.ne 0x100001ec8 <_rgb888_to_rgb565_neon_8vals+0xc4>
10100001e24: f9400828 ldr x8, [x1, #0x10]
11100001e28: f103211f cmp x8, #0xc8
12100001e2c: 54000501 b.ne 0x100001ecc <_rgb888_to_rgb565_neon_8vals+0xc8>
13100001e30: f9400c28 ldr x8, [x1, #0x18]
14100001e34: f103211f cmp x8, #0xc8
15100001e38: 540004c1 b.ne 0x100001ed0 <_rgb888_to_rgb565_neon_8vals+0xcc>
16100001e3c: d2800008 mov x8, #0x0 ; =0
17100001e40: d2800009 mov x9, #0x0 ; =0
18100001e44: d280000a mov x10, #0x0 ; =0
19100001e48: 4f008480 movi.8h v0, #0x4
20100001e4c: 4f008441 movi.8h v1, #0x2
21100001e50: 4f0087e2 movi.8h v2, #0x1f
22100001e54: 4f0187e3 movi.8h v3, #0x3f
23100001e58: f940000b ldr x11, [x0]
24100001e5c: 8b08016b add x11, x11, x8
25100001e60: 0c404164 ld3.8b { v4, v5, v6 }, [x11]
26100001e64: 2e241007 uaddw.8h v7, v0, v4
27100001e68: 2e251030 uaddw.8h v16, v1, v5
28100001e6c: 6f1d04e7 ushr.8h v7, v7, #0x3
29100001e70: 6f1e0610 ushr.8h v16, v16, #0x2
30100001e74: 2e261004 uaddw.8h v4, v0, v6
31100001e78: 6f1d0484 ushr.8h v4, v4, #0x3
32100001e7c: 6e626ce5 umin.8h v5, v7, v2
33100001e80: 6e636e06 umin.8h v6, v16, v3
34100001e84: 4f1b54a5 shl.8h v5, v5, #0xb
35100001e88: 4f1554c6 shl.8h v6, v6, #0x5
36100001e8c: 6e626c84 umin.8h v4, v4, v2
37100001e90: 4ea51cc5 orr.16b v5, v6, v5
38100001e94: 4ea41ca4 orr.16b v4, v5, v4
39100001e98: f940002b ldr x11, [x1]
40100001e9c: 3ca96964 str q4, [x11, x9]
41100001ea0: 9100214a add x10, x10, #0x8
42100001ea4: a941300b ldp x11, x12, [x0, #0x10]
43100001ea8: 9b0b7d8b mul x11, x12, x11
44100001eac: 91004129 add x9, x9, #0x10
45100001eb0: 91006108 add x8, x8, #0x18
46100001eb4: eb0a017f cmp x11, x10
47100001eb8: 54fffd08 b.hi 0x100001e58 <_rgb888_to_rgb565_neon_8vals+0x54>
48100001ebc: a8c17bfd ldp x29, x30, [sp], #0x10
49100001ec0: d65f03c0 ret

Processing 16 pixels per iteration (16P)

 1void rgb888_to_rgb565_neon_16_vals(Image *src, Image *dst) {
 2
 3 const uint16x8_t v_4 = vdupq_n_u16(4);
 4 const uint16x8_t v_2 = vdupq_n_u16(2);
 5 const uint16x8_t v_31 = vdupq_n_u16(31);
 6 const uint16x8_t v_63 = vdupq_n_u16(63);
 7
 8 uint8x16x3_t v_rgb888;
 9 uint16x8_t v_rgb565_high;
10 uint16x8_t v_rgb565_low;
11
12 for (int i = 0; i < src->img_width * src->img_height; i += 16) {
13
14 v_rgb888 = vld3q_u8(src->buffer + (i * 3));
15
16 uint16x8_t v_r8_high = vmovl_high_u8(v_rgb888.val[0]);
17 uint16x8_t v_r8_low = vmovl_u8(vget_low_u8(v_rgb888.val[0]));
18
19 uint16x8_t v_g8_high = vmovl_high_u8(v_rgb888.val[1]);
20 uint16x8_t v_g8_low = vmovl_u8(vget_low_u8(v_rgb888.val[1]));
21
22 uint16x8_t v_b8_high = vmovl_high_u8(v_rgb888.val[2]);
23 uint16x8_t v_b8_low = vmovl_u8(vget_low_u8(v_rgb888.val[2]));
24
25 v_r8_high = vaddq_u16(v_r8_high, v_4);
26 v_g8_high = vaddq_u16(v_g8_high, v_2);
27 v_b8_high = vaddq_u16(v_b8_high, v_4);
28
29 v_r8_low = vaddq_u16(v_r8_low, v_4);
30 v_g8_low = vaddq_u16(v_g8_low, v_2);
31 v_b8_low = vaddq_u16(v_b8_low, v_4);
32
33 v_r8_high = vshrq_n_u16(v_r8_high, 3);
34 v_g8_high = vshrq_n_u16(v_g8_high, 2);
35 v_b8_high = vshrq_n_u16(v_b8_high, 3);
36
37 v_r8_low = vshrq_n_u16(v_r8_low, 3);
38 v_g8_low = vshrq_n_u16(v_g8_low, 2);
39 v_b8_low = vshrq_n_u16(v_b8_low, 3);
40
41 v_r8_high = vminq_u16(v_r8_high, v_31);
42 v_g8_high = vminq_u16(v_g8_high, v_63);
43 v_b8_high = vminq_u16(v_b8_high, v_31);
44
45 v_r8_low = vminq_u16(v_r8_low, v_31);
46 v_g8_low = vminq_u16(v_g8_low, v_63);
47 v_b8_low = vminq_u16(v_b8_low, v_31);
48
49 v_r8_high = vshlq_n_u16(v_r8_high, 11);
50 v_g8_high = vshlq_n_u16(v_g8_high, 5);
51
52 v_r8_low = vshlq_n_u16(v_r8_low, 11);
53 v_g8_low = vshlq_n_u16(v_g8_low, 5);
54
55 v_rgb565_high = vorrq_u16(v_r8_high, v_g8_high);
56 v_rgb565_high = vorrq_u16(v_rgb565_high, v_b8_high);
57
58 v_rgb565_low = vorrq_u16(v_r8_low, v_g8_low);
59 v_rgb565_low = vorrq_u16(v_rgb565_low, v_b8_low);
60
61 vst1q_u16((uint16_t *)dst->buffer + i + 8, v_rgb565_high);
62 vst1q_u16((uint16_t *)dst->buffer + i, v_rgb565_low);
63 }
64}

 10000000100001ed4 <_rgb888_to_rgb565_neon_16_vals>:
 2100001ed4: a9bf7bfd stp x29, x30, [sp, #-0x10]!
 3100001ed8: 910003fd mov x29, sp
 4100001edc: f9400808 ldr x8, [x0, #0x10]
 5100001ee0: f103211f cmp x8, #0xc8
 6100001ee4: 54000781 b.ne 0x100001fd4 <_rgb888_to_rgb565_neon_16_vals+0x100>
 7100001ee8: f9400c08 ldr x8, [x0, #0x18]
 8100001eec: f103211f cmp x8, #0xc8
 9100001ef0: 54000741 b.ne 0x100001fd8 <_rgb888_to_rgb565_neon_16_vals+0x104>
10100001ef4: f9400828 ldr x8, [x1, #0x10]
11100001ef8: f103211f cmp x8, #0xc8
12100001efc: 54000701 b.ne 0x100001fdc <_rgb888_to_rgb565_neon_16_vals+0x108>
13100001f00: f9400c28 ldr x8, [x1, #0x18]
14100001f04: f103211f cmp x8, #0xc8
15100001f08: 540006c1 b.ne 0x100001fe0 <_rgb888_to_rgb565_neon_16_vals+0x10c>
16100001f0c: d2800008 mov x8, #0x0 ; =0
17100001f10: d2800009 mov x9, #0x0 ; =0
18100001f14: d280000a mov x10, #0x0 ; =0
19100001f18: 4f008480 movi.8h v0, #0x4
20100001f1c: 4f008441 movi.8h v1, #0x2
21100001f20: 4f0087e2 movi.8h v2, #0x1f
22100001f24: 4f0187e3 movi.8h v3, #0x3f
23100001f28: f940000b ldr x11, [x0]
24100001f2c: 8b08016b add x11, x11, x8
25100001f30: 4c404164 ld3.16b { v4, v5, v6 }, [x11]
26100001f34: 6e241007 uaddw2.8h v7, v0, v4
27100001f38: 6e251030 uaddw2.8h v16, v1, v5
28100001f3c: 6e261011 uaddw2.8h v17, v0, v6
29100001f40: 2e241012 uaddw.8h v18, v0, v4
30100001f44: 2e251033 uaddw.8h v19, v1, v5
31100001f48: 2e261004 uaddw.8h v4, v0, v6
32100001f4c: 6f1d04e5 ushr.8h v5, v7, #0x3
33100001f50: 6f1e0606 ushr.8h v6, v16, #0x2
34100001f54: 6f1d0627 ushr.8h v7, v17, #0x3
35100001f58: 6f1d0650 ushr.8h v16, v18, #0x3
36100001f5c: 6f1e0671 ushr.8h v17, v19, #0x2
37100001f60: 6f1d0484 ushr.8h v4, v4, #0x3
38100001f64: 6e626ca5 umin.8h v5, v5, v2
39100001f68: 6e636cc6 umin.8h v6, v6, v3
40100001f6c: 6e626ce7 umin.8h v7, v7, v2
41100001f70: 6e626e10 umin.8h v16, v16, v2
42100001f74: 6e636e31 umin.8h v17, v17, v3
43100001f78: 6e626c84 umin.8h v4, v4, v2
44100001f7c: 4f1b54a5 shl.8h v5, v5, #0xb
45100001f80: 4f1554c6 shl.8h v6, v6, #0x5
46100001f84: 4f1b5610 shl.8h v16, v16, #0xb
47100001f88: 4f155631 shl.8h v17, v17, #0x5
48100001f8c: 4ea51cc5 orr.16b v5, v6, v5
49100001f90: 4eb01e26 orr.16b v6, v17, v16
50100001f94: 4ea41cc4 orr.16b v4, v6, v4
51100001f98: f940002b ldr x11, [x1]
52100001f9c: 4ea71ca5 orr.16b v5, v5, v7
53100001fa0: 3ca96964 str q4, [x11, x9]
54100001fa4: f940002b ldr x11, [x1]
55100001fa8: 8b09016b add x11, x11, x9
56100001fac: 3d800565 str q5, [x11, #0x10]
57100001fb0: 9100414a add x10, x10, #0x10
58100001fb4: a941300b ldp x11, x12, [x0, #0x10]
59100001fb8: 9b0b7d8b mul x11, x12, x11
60100001fbc: 91008129 add x9, x9, #0x20
61100001fc0: 9100c108 add x8, x8, #0x30
62100001fc4: eb0a017f cmp x11, x10
63100001fc8: 54fffb08 b.hi 0x100001f28 <_rgb888_to_rgb565_neon_16_vals+0x54>
64100001fcc: a8c17bfd ldp x29, x30, [sp], #0x10
65100001fd0: d65f03c0 ret

Optimized version, processing 16 pixels per iteration (using masks)

 1void rgb888_to_rgb565_neon(Image *src, Image *dst) {
 2
 3 const uint8x16_t v_4 = vdupq_n_u8(4);
 4 const uint8x16_t v_2 = vdupq_n_u8(2);
 5 const uint8x16_t v_255 = vdupq_n_u8(255);
 6
 7 // expecting 200x200 image
 8 assert(src->img_width == TARGET_IMG_WIDTH);
 9 assert(src->img_height == TARGET_IMG_HEIGHT);
10 assert(dst->img_width == TARGET_IMG_WIDTH);
11 assert(dst->img_height == TARGET_IMG_HEIGHT);
12
13 uint8x16x3_t v_rgb888;
14 uint16x8_t v_rgb565_high;
15 uint16x8_t v_rgb565_low;
16
17 for (int i = 0; i < src->img_width * src->img_height; i += 16) {
18
19 v_rgb888 = vld3q_u8(src->buffer + (i * 3));
20
21 uint8x16_t v_r = v_rgb888.val[0];
22 uint8x16_t v_g = v_rgb888.val[1];
23 uint8x16_t v_b = v_rgb888.val[2];
24
25 v_r = vaddq_u8(v_r, v_4);
26 v_g = vaddq_u8(v_g, v_2);
27 v_b = vaddq_u8(v_b, v_4);
28
29 // handle overflow
30 uint8x16_t r_mask = vcgtq_u8(v_rgb888.val[0], v_r);
31 uint8x16_t g_mask = vcgtq_u8(v_rgb888.val[1], v_g);
32 uint8x16_t b_mask = vcgtq_u8(v_rgb888.val[2], v_b);
33
34 v_r = vbslq_u8(r_mask, v_255, v_r);
35 v_g = vbslq_u8(g_mask, v_255, v_g);
36 v_b = vbslq_u8(b_mask, v_255, v_b);
37
38 v_r = vshrq_n_u8(v_r, 3);
39 v_g = vshrq_n_u8(v_g, 2);
40 v_b = vshrq_n_u8(v_b, 3);
41
42 uint16x8_t v_r8_high = vmovl_high_u8(v_r);
43 uint16x8_t v_r8_low = vmovl_u8(vget_low_u8(v_r));
44
45 uint16x8_t v_g8_high = vmovl_high_u8(v_g);
46 uint16x8_t v_g8_low = vmovl_u8(vget_low_u8(v_g));
47
48 v_r8_high = vshlq_n_u16(v_r8_high, 11);
49 v_g8_high = vshlq_n_u16(v_g8_high, 5);
50
51 v_r8_low = vshlq_n_u16(v_r8_low, 11);
52 v_g8_low = vshlq_n_u16(v_g8_low, 5);
53
54 v_rgb565_high = vorrq_u16(v_r8_high, v_g8_high);
55 v_rgb565_high = vorrq_u16(v_rgb565_high, vmovl_high_u8(v_b));
56
57 v_rgb565_low = vorrq_u16(v_r8_low, v_g8_low);
58 v_rgb565_low = vorrq_u16(v_rgb565_low, vmovl_u8(vget_low_u8(v_b)));
59
60 vst1q_u16((uint16_t *)dst->buffer + i, v_rgb565_low);
61 vst1q_u16((uint16_t *)dst->buffer + i + 8, v_rgb565_high);
62 }
63}

Optimized version, processing 16 pixels per iteration (saturation add)

 1void rgb888_to_rgb565_neon(Image *src, Image *dst) {
 2
 3 const uint8x16_t v_4 = vdupq_n_u8(4);
 4 const uint8x16_t v_2 = vdupq_n_u8(2);
 5 const uint8x16_t v_255 = vdupq_n_u8(255);
 6
 7 // expecting 200x200 image
 8 assert(src->img_width == TARGET_IMG_WIDTH);
 9 assert(src->img_height == TARGET_IMG_HEIGHT);
10 assert(dst->img_width == TARGET_IMG_WIDTH);
11 assert(dst->img_height == TARGET_IMG_HEIGHT);
12
13 uint8x16x3_t v_rgb888;
14 uint16x8_t v_rgb565_high;
15 uint16x8_t v_rgb565_low;
16
17 for (int i = 0; i < src->img_width * src->img_height; i += 16) {
18
19 v_rgb888 = vld3q_u8(src->buffer + (i * 3));
20
21 uint8x16_t v_r = v_rgb888.val[0];
22 uint8x16_t v_g = v_rgb888.val[1];
23 uint8x16_t v_b = v_rgb888.val[2];
24
25 v_r = vqaddq_u8(v_r, v_4);
26 v_g = vqaddq_u8(v_g, v_2);
27 v_b = vqaddq_u8(v_b, v_4);
28
29 v_r = vshrq_n_u8(v_r, 3);
30 v_g = vshrq_n_u8(v_g, 2);
31 v_b = vshrq_n_u8(v_b, 3);
32
33 uint16x8_t v_r8_high = vmovl_high_u8(v_r);
34 uint16x8_t v_r8_low = vmovl_u8(vget_low_u8(v_r));
35
36 uint16x8_t v_g8_high = vmovl_high_u8(v_g);
37 uint16x8_t v_g8_low = vmovl_u8(vget_low_u8(v_g));
38
39 v_r8_high = vshlq_n_u16(v_r8_high, 11);
40 v_g8_high = vshlq_n_u16(v_g8_high, 5);
41
42 v_r8_low = vshlq_n_u16(v_r8_low, 11);
43 v_g8_low = vshlq_n_u16(v_g8_low, 5);
44
45 v_rgb565_high = vorrq_u16(v_r8_high, v_g8_high);
46 v_rgb565_high = vorrq_u16(v_rgb565_high, vmovl_high_u8(v_b));
47
48 v_rgb565_low = vorrq_u16(v_r8_low, v_g8_low);
49 v_rgb565_low = vorrq_u16(v_rgb565_low, vmovl_u8(vget_low_u8(v_b)));
50
51 vst1q_u16((uint16_t *)dst->buffer + i, v_rgb565_low);
52 vst1q_u16((uint16_t *)dst->buffer + i + 8, v_rgb565_high);
53 }
54}

Scalar Algorithm

 1void rgb888_to_rgb565_scalar(Image *src, Image *dst) {
 2
 3 for (int i = 0; i < src->img_width * src->img_height; i++) {
 4 uint8_t r = src->buffer[i * 3 + 0];
 5 uint8_t g = src->buffer[i * 3 + 1];
 6 uint8_t b = src->buffer[i * 3 + 2];
 7
 8 // Add half the lost precision before truncating
 9 uint16_t r5 = (r + 4) >> 3; // +4 is half of 8 (2^3)
10 uint16_t g6 = (g + 2) >> 2; // +2 is half of 4 (2^2)
11 uint16_t b5 = (b + 4) >> 3; // +4 is half of 8 (2^3)
12
13 // Clamp to prevent overflow
14 if (r5 > 31)
15 r5 = 31;
16 if (g6 > 63)
17 g6 = 63;
18 if (b5 > 31)
19 b5 = 31;
20
21 uint16_t value = (uint16_t)((r5 << 11) | (g6 << 5) | b5);
22
23 ((uint16_t *)dst->buffer)[i] = value;
24 }
25}

Scalar Algorithm (auto vectorized)

 10000000100001554 <_rgb888_to_rgb565_scalar>:
 2100001554: a9412408 ldp x8, x9, [x0, #0x10]
 3100001558: 9b087d28 mul x8, x9, x8
 410000155c: b4000988 cbz x8, 0x10000168c <_rgb888_to_rgb565_scalar+0x138>
 5100001560: f9400009 ldr x9, [x0]
 6100001564: f940002a ldr x10, [x1]
 7100001568: f100211f cmp x8, #0x8
 810000156c: 54000543 b.lo 0x100001614 <_rgb888_to_rgb565_scalar+0xc0>
 9100001570: d37ff90b lsl x11, x8, #1
 10100001574: 8b0b014c add x12, x10, x11
 11100001578: 8b08012d add x13, x9, x8
 1210000157c: 8b0b01ab add x11, x13, x11
 13100001580: eb0b015f cmp x10, x11
 14100001584: fa4c3122 ccmp x9, x12, #0x2, lo
 15100001588: 54000463 b.lo 0x100001614 <_rgb888_to_rgb565_scalar+0xc0>
 1610000158c: f100411f cmp x8, #0x10
 17100001590: 54000802 b.hs 0x100001690 <_rgb888_to_rgb565_scalar+0x13c>
 18100001594: d280000b mov x11, #0x0 ; =0
 19100001598: aa0b03ee mov x14, x11
 2010000159c: 927df10b and x11, x8, #0xfffffffffffffff8
 211000015a0: d37ff9cd lsl x13, x14, #1
 221000015a4: 8b0e01ac add x12, x13, x14
 231000015a8: 8b0c012c add x12, x9, x12
 241000015ac: 8b0d014d add x13, x10, x13
 251000015b0: cb0b01ce sub x14, x14, x11
 261000015b4: 4f008480 movi.8h v0, #0x4
 271000015b8: 4f008441 movi.8h v1, #0x2
 281000015bc: 4f0087e2 movi.8h v2, #0x1f
 291000015c0: 4f0187e3 movi.8h v3, #0x3f
 301000015c4: 0cdf4184 ld3.8b { v4, v5, v6 }, [x12], #24
 311000015c8: 2e241007 uaddw.8h v7, v0, v4
 321000015cc: 6f1d04e7 ushr.8h v7, v7, #0x3
 331000015d0: 2e251030 uaddw.8h v16, v1, v5
 341000015d4: 6f1e0610 ushr.8h v16, v16, #0x2
 351000015d8: 2e261004 uaddw.8h v4, v0, v6
 361000015dc: 6f1d0484 ushr.8h v4, v4, #0x3
 371000015e0: 6e626ce5 umin.8h v5, v7, v2
 381000015e4: 6e636e06 umin.8h v6, v16, v3
 391000015e8: 6e626c84 umin.8h v4, v4, v2
 401000015ec: 4f1b54a5 shl.8h v5, v5, #0xb
 411000015f0: 4f1554c6 shl.8h v6, v6, #0x5
 421000015f4: 4ea51cc5 orr.16b v5, v6, v5
 431000015f8: 4ea41ca4 orr.16b v4, v5, v4
 441000015fc: 3c8105a4 str q4, [x13], #0x10
 45100001600: b10021ce adds x14, x14, #0x8
 46100001604: 54fffe01 b.ne 0x1000015c4 <_rgb888_to_rgb565_scalar+0x70>
 47100001608: eb0b011f cmp x8, x11
 4810000160c: 54000061 b.ne 0x100001618 <_rgb888_to_rgb565_scalar+0xc4>
 49100001610: 1400001f b 0x10000168c <_rgb888_to_rgb565_scalar+0x138>
 50100001614: d280000b mov x11, #0x0 ; =0
 51100001618: d37ff96c lsl x12, x11, #1
 5210000161c: 8b0c014a add x10, x10, x12
 53100001620: 8b0b018c add x12, x12, x11
 54100001624: 8b090189 add x9, x12, x9
 55100001628: 91000929 add x9, x9, #0x2
 5610000162c: cb0b0108 sub x8, x8, x11
 57100001630: 528003eb mov w11, #0x1f ; =31
 58100001634: 528007ec mov w12, #0x3f ; =63
 59100001638: 385fe12d ldurb w13, [x9, #-0x2]
 6010000163c: 385ff12e ldurb w14, [x9, #-0x1]
 61100001640: 3840352f ldrb w15, [x9], #0x3
 62100001644: 110011ad add w13, w13, #0x4
 63100001648: 53037dad lsr w13, w13, #3
 6410000164c: 110009ce add w14, w14, #0x2
 65100001650: 53027dce lsr w14, w14, #2
 66100001654: 110011ef add w15, w15, #0x4
 67100001658: 53037def lsr w15, w15, #3
 6810000165c: 71007dbf cmp w13, #0x1f
 69100001660: 1a8b31ad csel w13, w13, w11, lo
 70100001664: 7100fddf cmp w14, #0x3f
 71100001668: 1a8c31ce csel w14, w14, w12, lo
 7210000166c: 71007dff cmp w15, #0x1f
 73100001670: 1a8b31ef csel w15, w15, w11, lo
 74100001674: 531b69ce lsl w14, w14, #5
 75100001678: 2a0d2dcd orr w13, w14, w13, lsl #11
 7610000167c: 2a0f01ad orr w13, w13, w15
 77100001680: 7800254d strh w13, [x10], #0x2
 78100001684: f1000508 subs x8, x8, #0x1
 79100001688: 54fffd81 b.ne 0x100001638 <_rgb888_to_rgb565_scalar+0xe4>
 8010000168c: d65f03c0 ret
 81100001690: 927ced0b and x11, x8, #0xfffffffffffffff0
 82100001694: 4f008480 movi.8h v0, #0x4
 83100001698: 4f008441 movi.8h v1, #0x2
 8410000169c: 4f0087e2 movi.8h v2, #0x1f
 851000016a0: 4f0187e3 movi.8h v3, #0x3f
 861000016a4: aa0b03ec mov x12, x11
 871000016a8: aa0a03ed mov x13, x10
 881000016ac: aa0903ee mov x14, x9
 891000016b0: 4cdf41c4 ld3.16b { v4, v5, v6 }, [x14], #48
 901000016b4: 6e241007 uaddw2.8h v7, v0, v4
 911000016b8: 2e241010 uaddw.8h v16, v0, v4
 921000016bc: 6f1d0610 ushr.8h v16, v16, #0x3
 931000016c0: 6f1d04e7 ushr.8h v7, v7, #0x3
 941000016c4: 6e251031 uaddw2.8h v17, v1, v5
 951000016c8: 2e251032 uaddw.8h v18, v1, v5
 961000016cc: 6f1e0652 ushr.8h v18, v18, #0x2
 971000016d0: 6f1e0631 ushr.8h v17, v17, #0x2
 981000016d4: 6e261013 uaddw2.8h v19, v0, v6
 991000016d8: 2e261004 uaddw.8h v4, v0, v6
1001000016dc: 6f1d0484 ushr.8h v4, v4, #0x3
1011000016e0: 6f1d0665 ushr.8h v5, v19, #0x3
1021000016e4: 6e626ce6 umin.8h v6, v7, v2
1031000016e8: 6e626e07 umin.8h v7, v16, v2
1041000016ec: 6e636e30 umin.8h v16, v17, v3
1051000016f0: 6e636e51 umin.8h v17, v18, v3
1061000016f4: 6e626ca5 umin.8h v5, v5, v2
1071000016f8: 6e626c84 umin.8h v4, v4, v2
1081000016fc: 4f1b54e7 shl.8h v7, v7, #0xb
109100001700: 4f1b54c6 shl.8h v6, v6, #0xb
110100001704: 4f155631 shl.8h v17, v17, #0x5
111100001708: 4f155610 shl.8h v16, v16, #0x5
11210000170c: 4ea61e06 orr.16b v6, v16, v6
113100001710: 4ea71e27 orr.16b v7, v17, v7
114100001714: 4ea41ce4 orr.16b v4, v7, v4
115100001718: 4ea51cc5 orr.16b v5, v6, v5
11610000171c: ac8115a4 stp q4, q5, [x13], #0x20
117100001720: f100418c subs x12, x12, #0x10
118100001724: 54fffc61 b.ne 0x1000016b0 <_rgb888_to_rgb565_scalar+0x15c>
119100001728: eb0b011f cmp x8, x11
12010000172c: 54fffb00 b.eq 0x10000168c <_rgb888_to_rgb565_scalar+0x138>
121100001730: 371ff348 tbnz w8, #0x3, 0x100001598 <_rgb888_to_rgb565_scalar+0x44>
122100001734: 17ffffb9 b 0x100001618 <_rgb888_to_rgb565_scalar+0xc4>

What Compilers Really Do: A SIMD Case Study

Mon, 01 Sep 2025 00:00:00 +0000

In a different post, I looked at optimizing a particular algorithm using Arm Neon SIMD. If you are interested in how to use SIMD to convert RGB888 to RGB565, definitely take a look at that post.

While trying different things and figuring out how to reduce the execution time as much as possible, I did a deep dive into the generated assembly code for different implementations of that algorithm as well as the code that the compiler generates when optimizing (and vectorizing) the scalar version.

This post focuses on what I learned about compilers and how to make them do what you want.

1. Compilers are really smart

Modern compilers are pretty good at optimizing algorithms, at least trivial ones. They make use of architecture specific instructions to get the most performance out of the target machine.

When optimizing this simple algorithm for example:

 1void rgb888_to_rgb565_scalar(Image *src, Image *dst) {
 2
 3 for (int i = 0; i < src->img_width * src->img_height; i++) {
 4 uint8_t r = src->buffer[i * 3 + 0];
 5 uint8_t g = src->buffer[i * 3 + 1];
 6 uint8_t b = src->buffer[i * 3 + 2];
 7
 8 // Add half the lost precision before truncating
 9 uint16_t r5 = (r + 4) >> 3; // +4 is half of 8 (2^3)
10 uint16_t g6 = (g + 2) >> 2; // +2 is half of 4 (2^2)
11 uint16_t b5 = (b + 4) >> 3; // +4 is half of 8 (2^3)
12
13 // Clamp to prevent overflow
14 if (r5 > 31)
15 r5 = 31;
16 if (g6 > 63)
17 g6 = 63;
18 if (b5 > 31)
19 b5 = 31;
20
21 uint16_t value = (uint16_t)((r5 << 11) | (g6 << 5) | b5);
22
23 ((uint16_t *)dst->buffer)[i] = value;
24 }
25}

The compiler essentially generates 3 functions. Or execution paths. One truly scalar version, one processing 8 pixels per iteration and one processing 16 pixels per iteration. Since Arm Neon registers are 128 bits wide, 16 8 bit values are the most that can fit into one register. The whole assembly is in the Appendix, I just want to draw your attention to a few small excerpts.

The following snippet shows the start of the function, and it contains the logic to decide which one of the aforementioned paths it should take.

 10000000100001554 <_rgb888_to_rgb565_scalar>:
 2100001554: a9412408 ldp x8, x9, [x0, #0x10]
 3100001558: 9b087d28 mul x8, x9, x8
 410000155c: b4000988 cbz x8, 0x10000168c <_rgb888_to_rgb565_scalar+0x138>
 5100001560: f9400009 ldr x9, [x0]
 6100001564: f940002a ldr x10, [x1]
 7100001568: f100211f cmp x8, #0x8
 810000156c: 54000543 b.lo 0x100001614 <_rgb888_to_rgb565_scalar+0xc0> ; if num pixel < 8, jump to scalar
 9100001570: d37ff90b lsl x11, x8, #1
10100001574: 8b0b014c add x12, x10, x11
11100001578: 8b08012d add x13, x9, x8
1210000157c: 8b0b01ab add x11, x13, x11
13100001580: eb0b015f cmp x10, x11
14100001584: fa4c3122 ccmp x9, x12, #0x2, lo
15100001588: 54000463 b.lo 0x100001614 <_rgb888_to_rgb565_scalar+0xc0>
1610000158c: f100411f cmp x8, #0x10
17100001590: 54000802 b.hs 0x100001690 <_rgb888_to_rgb565_scalar+0x13c> ; if num pixel >= jump to 16 pixel at a time
18// ... continue processing 8 pixels at a time

Making the compiler do what you want it to do

If you read my post on using SIMD to solve this problem efficiently, then you know that I have implemented different versions. Among them one that processes 8 pixels per iteration and one that processes 16 pixels per iteration by loading 3x16 values and then processing the higher 8 values and lower 8 values separately for each color channel, since it was not possible to keep the algorithm the same and truly process 16 values with each arithmetic instruction, since the values would overflow. There is a way to achieve this if you change the algorithm implementation a little, but more on that in SIMD Algorithm Design: Beyond Basic Vectorization.

And the compiler essentially did the same. In this post, we will only look at the 16 pixel version and ignore the 8 pixel one, since the former is more interesting in my opinion.

Before the rest of this post, a short section about terminology:

For the rest of this post I will refer to my ‘16 pixels per iteration’ implementation as 16P (short for ‘16 pixels version’), and I will refer to the code that the compiler generated when optimizing and vectorizing the scalar version as CGV, ’the compiler generated version’.

So when I talk about ’the assembly generated for 16P’ or ’the 16P assembly’, then I mean the assembly that the compiler generated when compiling my handwritten ‘16 pixels per iteration’ version. And when I mention ’the CGV’, I refer to the ‘16 pixels at a time’ part of the compiler generated version, and ’the CGV assembly’ refers to the specific instructions the compiler has generated for CGV.

Comparing CGV and 16P

So when comparing the 16P assembly and the CGV assembly, it is clear that the SIMD instructions are exactly the same. However, benchmarks reveal that CGV is a little bit faster overall.

So it is worthwhile to look at the loop code generated by the compiler (loop of 16P, loop of CGV).

What immediately becomes apparent is that number of instructions for 16P is higher than the number for CGV. Particularly at the beginning and at the end of the loop.

Beginning of the loop

The first ones are right at the beginning of the loop:

1100001f28: f940000b ldr x11, [x0] ; load base address (src->buffer) from memory
2100001f2c: 8b08016b add x11, x11, x8 ; add offset: i * 3
3100001f30: 4c404164 ld3.16b { v4, v5, v6 }, [x11] ; load 3 times 16 1 byte values from the source address into the registers v4-v6.

So for some reason the compiler loads something from memory (source address can be found in x0) into the register x11 and adds the content from x8 to it. The next instruction makes it painfully obvious what this is. It represents the interleaved load of 16 pixels (3 color channels times 16 1 byte values).

These 3 lines represent this line from the C code:

1v_rgb888 = vld3q_u8(src->buffer + (i * 3));

x8 contains i * 3 (is set to 0 before the loop code and is later increased by 0x30, which is 3 * 16 in hexadecimal, and i increases by 16 at each iteration), and the ldr instruction loads the buffer start address from the src struct, which is located in memory.

This has to be done at each iteration because the compiler doesn’t know that the value of buffer does not change.

An easy way to avoid this 2 instruction overhead is to save the value of buffer in a local variable that is placed outside of the loop:

1const uint8_t *src_ptr = src->buffer;
2
3for (int i = 0; i < src->img_width * src->img_height; i += 16) {
4 // ...
5}

The next couple of instructions are the same. The order is different, and it is possible that this improves pipelining. However, this does not cause any measurable performance difference, so it might just be a coincidence. Furthermore, it is difficult to reason about this without knowing the details of the underlying hardware, which Apple has not made public. The next difference is at the end of the loop after all the Neon instructions.

End of the loop

The CGV ends with these 3 instructions:

110000171c: ac8115a4 stp q4, q5, [x13], #0x20 ; save result to dst->buffer
2100001720: f100418c subs x12, x12, #0x10 ; decrement x12 by 0x10 (16 in decimal)
3100001724: 54fffc61 b.ne 0x1000016b0 <_rgb888_to_rgb565_scalar+0x15c> ; branch

The first instruction saves the computation result back to memory using one instruction to save both buffers to their particular offsets. The values to be saved are in q4 and q5, they are saved to the location in x13 and said location is incremented by 32.

The next 2 instructions decrement the value in x12 by 16 and branch to the start of the loop if that value is not equal to 0. So what the compiler actually did is convert the for loop to a while loop:

 1for (int i = 0; i < src->img_width * src->img_height; i++) {
 2 // ...
 3}
 4
 5// to
 6
 7int remaining_pixels = src->img_width * src->img_height;
 8while (remaining_pixels > 0) {
 9 // ...
10 remaining_pixels -= 16;
11}

Meanwhile, the compiler generated the following instructions for 16P:

 1100001f98: f940002b ldr x11, [x1] ; load a value from memory (location in x1 aka dst->buffer) to x11
 2; ... omitted one neon function that has not yet been exectued, probably due to pipelining
 3100001fa0: 3ca96964 str q4, [x11, x9] ; store q4 (half of the 16 values) to base address + (2 * i)
 4100001fa4: f940002b ldr x11, [x1] ; load a value from memory (location in x1 aka dst->buffer) to x11
 5100001fa8: 8b09016b add x11, x11, x9 ; x11 = dst->buffer + (2 * i)
 6100001fac: 3d800565 str q5, [x11, #0x10] ; store q5 into dst->buffer + (2 * i) + 16
 7100001fb0: 9100414a add x10, x10, #0x10 ; add 16 to x10 (i+=16)
 8100001fb4: a941300b ldp x11, x12, [x0, #0x10] ; load x0 into x11 and x0 + 16 into x12 (img width and height)
 9100001fb8: 9b0b7d8b mul x11, x12, x11 ; multiply x11 with x12 (num pixels = img->width * img->height)
10100001fbc: 91008129 add x9, x9, #0x20 ; x9 += 32 (16 values * 2 bytes)
11100001fc0: 9100c108 add x8, x8, #0x30 ; x8 += 48
12100001fc4: eb0a017f cmp x11, x10 ; compare x11 and x10
13100001fc8: 54fffb08 b.hi 0x100001f28 <_rgb888_to_rgb565_neon_16_vals+0x54> ; branch if num_pixels > i

What becomes immediately apparent is that there is not ‘store pair’ (stp) instruction, but there are 2 ‘store’ (str) instructions instead. This stp instruction accepts two SIMD registers as inputs, which makes vectorizing the memory access possible as well. The addressing to figure out where to store the results is also more complicated, and so is the branching logic.

Starting with the store operations, here is the corresponding C code:

1vst1q_u16((uint16_t *)dst->buffer + i + 8, v_rgb565_high);
2vst1q_u16((uint16_t *)dst->buffer + i, v_rgb565_low);

The ldr pattern should seem familiar, since we encountered the exact same issue at the beginning of the loop, and the reason as well as the solution is the same here. x1 contains the location of the destination buffer, x9 is 2 * i (due to 16-bit integer addressing). The compiler reloads the destination address before every store, which also prevents it to replace those two individual str instructions with a more efficient stp instruction.

One way to get this ‘store pair’ instruction is by making the compiler understand that the address does not change:

1uint16_t *dst_ptr = (uint16_t *)dst->buffer + i;
2vst1q_u16(dst_ptr, v_rgb565_low);
3vst1q_u16(dst_ptr + 8, v_rgb565_high);

This yields the following assembly, and as you can see we now have a single store (stp) instead of two stores (2x str):

 11000020ac: f940002b ldr x11, [x1]
 21000020b0: 8b09016b add x11, x11, x9
 31000020b4: ad001564 stp q4, q5, [x11]
 41000020b8: 9100414a add x10, x10, #0x10
 51000020bc: a941300b ldp x11, x12, [x0, #0x10]
 61000020c0: 9b0b7d8b mul x11, x12, x11
 71000020c4: 91008129 add x9, x9, #0x20
 81000020c8: 9100c108 add x8, x8, #0x30
 91000020cc: eb0a017f cmp x11, x10
101000020d0: 54fffb48 b.hi 0x100002038 <_rgb888_to_rgb565_neon_16_vals_sp+0x54>

However, the compiler still does not know that the value of dst->buffer does not change in between iterations, so it has to load it in every loop and add the offset. This is now exactly the same as in the beginning of the loop, and the solution is also the same:

1uint16_t *dst_ptr = (uint16_t *)dst->buffer;
2const uint8_t *src_ptr = src->buffer;
3
4for (int i = 0; i < src->img_width * src->img_height; i += 16) {
5 // ...
6}

This reduces the instructions at the end of the loop from 12 to 7:

11000021b0: ad3f9544 stp q4, q5, [x10, #-0x10] ; store to dst->buffer
21000021b4: 91004108 add x8, x8, #0x10 ; i+=16
31000021b8: a941300b ldp x11, x12, [x0, #0x10] ; load image dimensions
41000021bc: 9b0b7d8b mul x11, x12, x11 ; calculate number of pixels in image
51000021c0: 9100814a add x10, x10, #0x20 ; calculate offset for dst->buffer for the next iteration
61000021c4: eb08017f cmp x11, x8 ; if number pixels > i:
71000021c8: 54fffbe8 b.hi 0x100002144 <_rgb888_to_rgb565_neon_16_vals_sp_restrict+0x58> ; branch

This is still 4 more than the CGV assembly, and to explain that discrepancy we have to examine the looping behavior. I already mentioned that the compiler converted the for loop into essentially a while loop, which costs 2 instructions, while the for loop costs 5. Part of that is that the inline calculation of the number of pixels could not be optimized by the compiler, so it loads the image dimensions in every loop.

1const int num_pixels = src->img_width * src->img_height;
2for (int i = 0; i < num_pixels; i += 16) {
3 // ...
4}

Moving that calculation out of the loop gets rid of the extra load instruction and the multiplication, as these are moved out of the loop, but it keeps the cmp and adds a lsr instruction, which shifts the value in x10 (i) by 4. The comparison changed as well:

1100001c84: ad3fc526 stp q6, q17, [x9, #-0x10] ; store to dst->buffer
2100001c88: 9100414a add x10, x10, #0x10 ; i+=16
3100001c8c: 91008129 add x9, x9, #0x20 ; calculate offset for dst->buffer for the next iteration
4100001c90: d344fd4b lsr x11, x10, #4 ; i >> 4
5100001c94: f1270d7f cmp x11, #0x9c3 ; (i >> 4) < 2499?
6100001c98: 54fffc43 b.lo 0x100001c20 <_rgb888_to_rgb565_neon_sp+0x60> ; branch if (i >> 4) < 2499

So the compiler still cannot convert it to a while loop like it can in the compiler optimized version. The reason for that is that the compiler doesn’t know that/if the image dimensions are divisible by 16, but we know that they are in this case (200x200 pixels = 40 000 pixels, divided by 16 = 2 500 iterations).

However, we can tell the compiler that by changing the comparison from i < num_pixels to i != num_pixels. This lets the compiler know that i does not surpass the number of pixels.

1const int num_pixels = src->img_width * src->img_height;
2for (int i = 0; i != num_pixels; i += 16) {
3 // ...
4}

After that the generated instructions are almost equal to CGV:

1100001c84: ad3fc526 stp q6, q17, [x9, #-0x10]
2100001c88: 91008129 add x9, x9, #0x20
3100001c8c: f100414a subs x10, x10, #0x10
4100001c90: 54fffc81 b.ne 0x100001c20 <_rgb888_to_rgb565_neon_sp+0x60>

The only difference is that there is an extra add instruction to compute the next offset that the program should write to. In CGV that is done as part of the stp instruction.

Here is a side by side comparison¹:

opcode	source 1	source 2	destination	offset
`stp`	`q4`	`q5`	`[x13]`	+32 (post-index)
`stp`	`q6`	`q17`	`x9`	-16 (pre-index)

So the difference is that in the CGV version both register contents are stored to the address at [x13] and then the offset is incremented by 32. So an extra add instruction is not necessary.

But for some reason the compiler didn’t do this for the 16P version. In the assembly for 16P the destination address is stored in x9, the register contents are saved at x9-16 and then the destination address is incremented by 32 (add x9, x9, #0x20).

It is not entirely clear to me why the compiler does it that way. But one way to get it to generate the same instructions is to change the addressing like this:

1// from
2vst1q_u16(dst_ptr + i, v_rgb565_low);
3vst1q_u16(dst_ptr + i + 8, v_rgb565_high);
4
5// to
6vst1q_u16(dst_ptr, v_rgb565_low);
7dst_ptr += 8;
8vst1q_u16(dst_ptr, v_rgb565_high);
9dst_ptr += 8;

That way the compiler generates the same instructions for both 16P and CGV.

1100001c80: ac814506 stp q6, q17, [x8], #0x20
2100001c84: f100414a subs x10, x10, #0x10
3100001c88: 54fffca1 b.ne 0x100001c1c <_rgb888_to_rgb565_neon_sp+0x5c>

Conclusion

To conclude, we have a looked at a rather simple algorithm that has both been vectorized by hand by the compiler. During the comparisons there have been several observations made that lead to the following conclusions:

Compilers are really smart

They might optimize your problem just as well, if not better than you do, at least for trivial problems. Also doing manual optimizations might end up confusing the compiler, so it can’t do its best work.

Be aware what the compiler knows and what it doesn’t

Many of these changes in assembly were because the compiler could not know about the influence of other code on data and therefore had to play it safe, which resulted in extra instructions and an observable performance penalty.

Pre-calculate what you can

The compiler does not necessarily move calculations out of a loop, even though the result does not change across iterations. Moving calculations out of a hot-loop and caching the results can be worth it. Especially when the calculations are expensive.

Be as expressive as you can be

Some things that might be obvious to you are not clear to the compiler, and generally the more expressive your code is, the better the compiler performs when generating the code that eventually runs on the CPU. However, one or two add instructions might be a worthwhile cost for less verbose/more concise and thereby more readable code. But if you want to make sure the compiler does the best it can, being more expressive is usually the way to achieve that.

Appendix

Scalar Algorithm (auto vectorized)

 10000000100001554 <_rgb888_to_rgb565_scalar>:
 2100001554: a9412408 ldp x8, x9, [x0, #0x10]
 3100001558: 9b087d28 mul x8, x9, x8
 410000155c: b4000988 cbz x8, 0x10000168c <_rgb888_to_rgb565_scalar+0x138>
 5100001560: f9400009 ldr x9, [x0]
 6100001564: f940002a ldr x10, [x1]
 7100001568: f100211f cmp x8, #0x8
 810000156c: 54000543 b.lo 0x100001614 <_rgb888_to_rgb565_scalar+0xc0>
 9100001570: d37ff90b lsl x11, x8, #1
 10100001574: 8b0b014c add x12, x10, x11
 11100001578: 8b08012d add x13, x9, x8
 1210000157c: 8b0b01ab add x11, x13, x11
 13100001580: eb0b015f cmp x10, x11
 14100001584: fa4c3122 ccmp x9, x12, #0x2, lo
 15100001588: 54000463 b.lo 0x100001614 <_rgb888_to_rgb565_scalar+0xc0>
 1610000158c: f100411f cmp x8, #0x10
 17100001590: 54000802 b.hs 0x100001690 <_rgb888_to_rgb565_scalar+0x13c>
 18100001594: d280000b mov x11, #0x0 ; =0
 19100001598: aa0b03ee mov x14, x11
 2010000159c: 927df10b and x11, x8, #0xfffffffffffffff8
 211000015a0: d37ff9cd lsl x13, x14, #1
 221000015a4: 8b0e01ac add x12, x13, x14
 231000015a8: 8b0c012c add x12, x9, x12
 241000015ac: 8b0d014d add x13, x10, x13
 251000015b0: cb0b01ce sub x14, x14, x11
 261000015b4: 4f008480 movi.8h v0, #0x4
 271000015b8: 4f008441 movi.8h v1, #0x2
 281000015bc: 4f0087e2 movi.8h v2, #0x1f
 291000015c0: 4f0187e3 movi.8h v3, #0x3f
 301000015c4: 0cdf4184 ld3.8b { v4, v5, v6 }, [x12], #24
 311000015c8: 2e241007 uaddw.8h v7, v0, v4
 321000015cc: 6f1d04e7 ushr.8h v7, v7, #0x3
 331000015d0: 2e251030 uaddw.8h v16, v1, v5
 341000015d4: 6f1e0610 ushr.8h v16, v16, #0x2
 351000015d8: 2e261004 uaddw.8h v4, v0, v6
 361000015dc: 6f1d0484 ushr.8h v4, v4, #0x3
 371000015e0: 6e626ce5 umin.8h v5, v7, v2
 381000015e4: 6e636e06 umin.8h v6, v16, v3
 391000015e8: 6e626c84 umin.8h v4, v4, v2
 401000015ec: 4f1b54a5 shl.8h v5, v5, #0xb
 411000015f0: 4f1554c6 shl.8h v6, v6, #0x5
 421000015f4: 4ea51cc5 orr.16b v5, v6, v5
 431000015f8: 4ea41ca4 orr.16b v4, v5, v4
 441000015fc: 3c8105a4 str q4, [x13], #0x10
 45100001600: b10021ce adds x14, x14, #0x8
 46100001604: 54fffe01 b.ne 0x1000015c4 <_rgb888_to_rgb565_scalar+0x70>
 47100001608: eb0b011f cmp x8, x11
 4810000160c: 54000061 b.ne 0x100001618 <_rgb888_to_rgb565_scalar+0xc4>
 49100001610: 1400001f b 0x10000168c <_rgb888_to_rgb565_scalar+0x138>
 50100001614: d280000b mov x11, #0x0 ; =0
 51100001618: d37ff96c lsl x12, x11, #1
 5210000161c: 8b0c014a add x10, x10, x12
 53100001620: 8b0b018c add x12, x12, x11
 54100001624: 8b090189 add x9, x12, x9
 55100001628: 91000929 add x9, x9, #0x2
 5610000162c: cb0b0108 sub x8, x8, x11
 57100001630: 528003eb mov w11, #0x1f ; =31
 58100001634: 528007ec mov w12, #0x3f ; =63
 59100001638: 385fe12d ldurb w13, [x9, #-0x2]
 6010000163c: 385ff12e ldurb w14, [x9, #-0x1]
 61100001640: 3840352f ldrb w15, [x9], #0x3
 62100001644: 110011ad add w13, w13, #0x4
 63100001648: 53037dad lsr w13, w13, #3
 6410000164c: 110009ce add w14, w14, #0x2
 65100001650: 53027dce lsr w14, w14, #2
 66100001654: 110011ef add w15, w15, #0x4
 67100001658: 53037def lsr w15, w15, #3
 6810000165c: 71007dbf cmp w13, #0x1f
 69100001660: 1a8b31ad csel w13, w13, w11, lo
 70100001664: 7100fddf cmp w14, #0x3f
 71100001668: 1a8c31ce csel w14, w14, w12, lo
 7210000166c: 71007dff cmp w15, #0x1f
 73100001670: 1a8b31ef csel w15, w15, w11, lo
 74100001674: 531b69ce lsl w14, w14, #5
 75100001678: 2a0d2dcd orr w13, w14, w13, lsl #11
 7610000167c: 2a0f01ad orr w13, w13, w15
 77100001680: 7800254d strh w13, [x10], #0x2
 78100001684: f1000508 subs x8, x8, #0x1
 79100001688: 54fffd81 b.ne 0x100001638 <_rgb888_to_rgb565_scalar+0xe4>
 8010000168c: d65f03c0 ret
 81100001690: 927ced0b and x11, x8, #0xfffffffffffffff0
 82100001694: 4f008480 movi.8h v0, #0x4
 83100001698: 4f008441 movi.8h v1, #0x2
 8410000169c: 4f0087e2 movi.8h v2, #0x1f
 851000016a0: 4f0187e3 movi.8h v3, #0x3f
 861000016a4: aa0b03ec mov x12, x11
 871000016a8: aa0a03ed mov x13, x10
 881000016ac: aa0903ee mov x14, x9
 891000016b0: 4cdf41c4 ld3.16b { v4, v5, v6 }, [x14], #48
 901000016b4: 6e241007 uaddw2.8h v7, v0, v4
 911000016b8: 2e241010 uaddw.8h v16, v0, v4
 921000016bc: 6f1d0610 ushr.8h v16, v16, #0x3
 931000016c0: 6f1d04e7 ushr.8h v7, v7, #0x3
 941000016c4: 6e251031 uaddw2.8h v17, v1, v5
 951000016c8: 2e251032 uaddw.8h v18, v1, v5
 961000016cc: 6f1e0652 ushr.8h v18, v18, #0x2
 971000016d0: 6f1e0631 ushr.8h v17, v17, #0x2
 981000016d4: 6e261013 uaddw2.8h v19, v0, v6
 991000016d8: 2e261004 uaddw.8h v4, v0, v6
1001000016dc: 6f1d0484 ushr.8h v4, v4, #0x3
1011000016e0: 6f1d0665 ushr.8h v5, v19, #0x3
1021000016e4: 6e626ce6 umin.8h v6, v7, v2
1031000016e8: 6e626e07 umin.8h v7, v16, v2
1041000016ec: 6e636e30 umin.8h v16, v17, v3
1051000016f0: 6e636e51 umin.8h v17, v18, v3
1061000016f4: 6e626ca5 umin.8h v5, v5, v2
1071000016f8: 6e626c84 umin.8h v4, v4, v2
1081000016fc: 4f1b54e7 shl.8h v7, v7, #0xb
109100001700: 4f1b54c6 shl.8h v6, v6, #0xb
110100001704: 4f155631 shl.8h v17, v17, #0x5
111100001708: 4f155610 shl.8h v16, v16, #0x5
11210000170c: 4ea61e06 orr.16b v6, v16, v6
113100001710: 4ea71e27 orr.16b v7, v17, v7
114100001714: 4ea41ce4 orr.16b v4, v7, v4
115100001718: 4ea51cc5 orr.16b v5, v6, v5
11610000171c: ac8115a4 stp q4, q5, [x13], #0x20
117100001720: f100418c subs x12, x12, #0x10
118100001724: 54fffc61 b.ne 0x1000016b0 <_rgb888_to_rgb565_scalar+0x15c>
119100001728: eb0b011f cmp x8, x11
12010000172c: 54fffb00 b.eq 0x10000168c <_rgb888_to_rgb565_scalar+0x138>
121100001730: 371ff348 tbnz w8, #0x3, 0x100001598 <_rgb888_to_rgb565_scalar+0x44>
122100001734: 17ffffb9 b 0x100001618 <_rgb888_to_rgb565_scalar+0xc4>

Loop (auto vectorized)

 11000016b0: 4cdf41c4 ld3.16b { v4, v5, v6 }, [x14], #48
 21000016b4: 6e241007 uaddw2.8h v7, v0, v4
 31000016b8: 2e241010 uaddw.8h v16, v0, v4
 41000016bc: 6f1d0610 ushr.8h v16, v16, #0x3
 51000016c0: 6f1d04e7 ushr.8h v7, v7, #0x3
 61000016c4: 6e251031 uaddw2.8h v17, v1, v5
 71000016c8: 2e251032 uaddw.8h v18, v1, v5
 81000016cc: 6f1e0652 ushr.8h v18, v18, #0x2
 91000016d0: 6f1e0631 ushr.8h v17, v17, #0x2
101000016d4: 6e261013 uaddw2.8h v19, v0, v6
111000016d8: 2e261004 uaddw.8h v4, v0, v6
121000016dc: 6f1d0484 ushr.8h v4, v4, #0x3
131000016e0: 6f1d0665 ushr.8h v5, v19, #0x3
141000016e4: 6e626ce6 umin.8h v6, v7, v2
151000016e8: 6e626e07 umin.8h v7, v16, v2
161000016ec: 6e636e30 umin.8h v16, v17, v3
171000016f0: 6e636e51 umin.8h v17, v18, v3
181000016f4: 6e626ca5 umin.8h v5, v5, v2
191000016f8: 6e626c84 umin.8h v4, v4, v2
201000016fc: 4f1b54e7 shl.8h v7, v7, #0xb
21100001700: 4f1b54c6 shl.8h v6, v6, #0xb
22100001704: 4f155631 shl.8h v17, v17, #0x5
23100001708: 4f155610 shl.8h v16, v16, #0x5
2410000170c: 4ea61e06 orr.16b v6, v16, v6
25100001710: 4ea71e27 orr.16b v7, v17, v7
26100001714: 4ea41ce4 orr.16b v4, v7, v4
27100001718: 4ea51cc5 orr.16b v5, v6, v5
2810000171c: ac8115a4 stp q4, q5, [x13], #0x20
29100001720: f100418c subs x12, x12, #0x10
30100001724: 54fffc61 b.ne 0x1000016b0 <_rgb888_to_rgb565_scalar+0x15c>

Loop (hand optimized)

 1100001f28: f940000b ldr x11, [x0]
 2100001f2c: 8b08016b add x11, x11, x8
 3100001f30: 4c404164 ld3.16b { v4, v5, v6 }, [x11]
 4100001f34: 6e241007 uaddw2.8h v7, v0, v4
 5100001f38: 6e251030 uaddw2.8h v16, v1, v5
 6100001f3c: 6e261011 uaddw2.8h v17, v0, v6
 7100001f40: 2e241012 uaddw.8h v18, v0, v4
 8100001f44: 2e251033 uaddw.8h v19, v1, v5
 9100001f48: 2e261004 uaddw.8h v4, v0, v6
10100001f4c: 6f1d04e5 ushr.8h v5, v7, #0x3
11100001f50: 6f1e0606 ushr.8h v6, v16, #0x2
12100001f54: 6f1d0627 ushr.8h v7, v17, #0x3
13100001f58: 6f1d0650 ushr.8h v16, v18, #0x3
14100001f5c: 6f1e0671 ushr.8h v17, v19, #0x2
15100001f60: 6f1d0484 ushr.8h v4, v4, #0x3
16100001f64: 6e626ca5 umin.8h v5, v5, v2
17100001f68: 6e636cc6 umin.8h v6, v6, v3
18100001f6c: 6e626ce7 umin.8h v7, v7, v2
19100001f70: 6e626e10 umin.8h v16, v16, v2
20100001f74: 6e636e31 umin.8h v17, v17, v3
21100001f78: 6e626c84 umin.8h v4, v4, v2
22100001f7c: 4f1b54a5 shl.8h v5, v5, #0xb
23100001f80: 4f1554c6 shl.8h v6, v6, #0x5
24100001f84: 4f1b5610 shl.8h v16, v16, #0xb
25100001f88: 4f155631 shl.8h v17, v17, #0x5
26100001f8c: 4ea51cc5 orr.16b v5, v6, v5
27100001f90: 4eb01e26 orr.16b v6, v17, v16
28100001f94: 4ea41cc4 orr.16b v4, v6, v4
29100001f98: f940002b ldr x11, [x1]
30100001f9c: 4ea71ca5 orr.16b v5, v5, v7
31100001fa0: 3ca96964 str q4, [x11, x9]
32100001fa4: f940002b ldr x11, [x1]
33100001fa8: 8b09016b add x11, x11, x9
34100001fac: 3d800565 str q5, [x11, #0x10]
35100001fb0: 9100414a add x10, x10, #0x10
36100001fb4: a941300b ldp x11, x12, [x0, #0x10]
37100001fb8: 9b0b7d8b mul x11, x12, x11
38100001fbc: 91008129 add x9, x9, #0x20
39100001fc0: 9100c108 add x8, x8, #0x30
40100001fc4: eb0a017f cmp x11, x10
41100001fc8: 54fffb08 b.hi 0x100001f28 <_rgb888_to_rgb565_neon_16_vals+0x54>

STP Documentation ↩︎