More Arm Compilation Options in Rust

No sooner had I published the last piece than I found something really cool that I don't think is that well known.

The Cortex-M33 is an Armv8-M processor - that is, it implements the Microcontroller Profile part of Version 8 of the Arm Architecture Specifcation.

The Cortex-M55 and Cortex-M85 are Armv8.1-M processors - they implement Version 8.1. I sort of knew this, but didn't pay any real attention to what it means. But I should have done.

Branch and Loop Instructions

Armv8.1-M introduces new Branch and Loop Instructions. They are listed at https://developer.arm.com/documentation/101928/0101/The-Cortex-M85-Instruction-Set--Reference-Material/Armv8-1-M-branch-and-loop-instructions/List-of-Armv8-1-M-branch-and-loop-instructions, but I'll try and explain with some code examples.

A basic loop

Let's say we want to process some data.






#[no_mangle]
pub fn double_values(data: &mut [u8]) {
    for item in data.iter_mut() {
        *item = *item * 2;
    }
}

Let's compile for Armv8-M Mainline, with opt-level=s.


rustc sample.rs --emit asm --target=thumbv8m.main-none-eabi --edition 2021 --crate-type=rlib -C opt-level=s
cat sample.s | grep -v -e "\s\.[a-z]" -e "^\."

We get:










double_values:
        cbz    r1, .LBB0_2
.LBB0_1:
        ldrb   r2, [r0]
        subs   r1, #1
        lsl.w  r2, r2, #1
        strb   r2, [r0], #1
        bne    .LBB0_1
.LBB0_2:
        bx     lr

This is roughly:

Line 2: If r1 is zero, leave
Line 4: Load a byte from a pointer in r0, into r2
Line 5: Subtract 1 from r1
Line 6: Double the value in r2
Line 7: Store a byte to the pointer in r0, and then increment r0 by 1
Line 8: Loop back to Line 4 if r1 is not zero

If we want to process, say, 46 bytes, this will loop 46 times and it will take roughly 370 clock cycles.

If we compile for opt-level=3, we get a lot of loop unrolling but no new instructions.

Now with Armv8.1-M

Let's now tell LLVM we have a Cortex-M55, and we want to do opt-level=2.


rustc sample.rs --emit asm --target=thumbv8m.main-none-eabi --edition 2021 --crate-type=rlib -C opt-level=2 -C target-cpu=cortex-m55
cat sample.s | grep -v -e "\s\.[a-z]" -e "^\."

We get:













double_values:
        push      {r7, lr}
        mov       r7, sp
        cmp       r1, #0
        it        eq
        popeq     {r7, pc}
        dlstp.8   lr, r1
.LBB0_2:
        vldrb.u8  q0, [r0]
        vshl.i8   q0, q0, #1
        vstrb.8   q0, [r0], #16
        letp      lr, .LBB0_2
        pop       {r7, pc}

It didn't do any loop-unrolling! But what did it do?

Line 4-6: Check if the slice length is zero and if so, return immediately
Line 7: Setup a do-loop with tail predication
- The length of the loop is in r1
- Use lr to count how many items are left
Line 9: Vector load N bytes from the pointer in r0 to the 128-bit register q0
- N will either be 16, or lr, whichever is smaller
Line 10: Vector shift left each of the N bytes in q0
Line 11: Vector store N bytes from q0 to the pointer in r0
Line 12: Decrement lr and if it is not zero, return to the label on Line 8

As I understand it, the letp instruction isn't even really an instruction that needs to be executed. The loop state is held within the processor outside of the normal registers, and resetting PC back to the loop start and doing the loop decrement effectively takes zero cycles. This loop will take

The impressive thing here is that we didn't have to have any instructions for "handle this in units of 16 bytes, and once that's done, deal with whatever remainder is left over one byte at a time". It's all done in hardware - during a 'do loop', the vector instructions process either 16 bytes, or the number of bytes remaining if you're at the end of the slice. If we want to process 46 bytes, this loop repeats only 3 times - with bytes 0..=15, 16..=31 and 32..=45. Yet it's no bigger, in terms of code space, than the old opt-level=s loop.

Conclusion

With Rust and Armv8.1-M Branch and Loop Extensions, we get very small code and very fast code - an excellent combination. And I would to see stable support for recompiling libcore to take advantage of these kinds of new instructions, or a new thumbv81m.main-none-eabi{hf,} pair of targets which default to using at least Integer MVE, if not Float MVE.