compiling Mbed TLS for cortex-m0 with optimization and ARMC6 compiler results in error

[RonEld]

Description

• Type: Bug
• Priority: Major
  compilation error with ARMC6 toolchain, on cortex-m0 and optimization flag

---

Bug

OS
linux

mbed TLS build:
Version: 2.6.0
OS version: Ubuntu 16.04

ARMC6
Additional environment information:

Expected behavior
compilation to succeed
Actual behavior
compilation error:

./library/bignum.c:1130:9: error: inline assembly requires more registers than available
        MULADDC_INIT
        ^
./include/mbedtls/bn_mul.h:581:13: note: expanded from macro 'MULADDC_INIT'
            "ldr    r0, %3                      \n\t"   \
            ^
./library/bignum.c:1145:9: error: inline assembly requires more registers than available
        MULADDC_INIT
        ^

Steps to reproduce
compile using ARMC6 with optimization, such as -Os
Reproduces only for cortex-m0

armclang --target=arm-arm-none-eabi -Os -mthumb -Wno-armcc-pragma-push-pop -Wno-armcc-pragma-anon-unions -mcpu=cortex-m0 -march=armv7-m -I./include -D__ASSERT_MSG -std=gnu99 -o library/bignum.o ./library/bignum.c

Note:
Can be worked around using -DMULADDC_CANNOT_USE_R7 compilation flag, or without optimization flag, but this will compile without the assmebly optimization

[ciarmcom]

ARM Internal Ref: IOTSSL-1704

[mpg]

By the way, could we test how big a difference this assembly "optimization" makes? I'm not sure it's that significant.

(Of course this issue still needs to be fixed. It's just that we seem to assume this assembly is very important to have, while I'm firmly of the opinion that nothing is faster until you actually measure it.)

[RonEld]

@mpg #1964 shows results of benchmark application with and without the assembly, for a 64 bit limb on bignum. You can see that there is significant improvement in the performance, mostly in RSA

[mpg]

While the measurements in #1964 are a very interesting data point, V8-A and V6-M are pretty different architectures performance-wise, for example in terms the multiplication instructions they have or the number of registers. Also, obviously the performance of handwritten assembly depends quite a lot on how it's written, and how much in improves compare to compiler-generated code depends on how good the compiler backend is for that particular platform and that particular kind of operation (sometimes C cannot express the best way a CPU could perform an operation, sometimes it can). So I'm not sure how much one can extrapolate from one case to the other.

Don't get me wrong, I'm not saying this particular bit of asm on this particular platform is not worth it, I'm just saying I'd like us to make decisions based on actual specific data. I assume the person who contributed #1964 would agree, because they started by showing us some specific data right away. I'm just saying I'd like to have the same kind of data here too.

OTOH, after looking a bit at this bit of asm, I'm thinking fixing could be as easy as using some other register number: it looks like r10 to r12 would be free for use in the thumb case, and even r8-r12 in the thumb2 case. (It seems the author of this asm just used registers in order, perhaps not being aware of r7's special role for some compilers with some options.) If fixing is that easy, I'd be happy with a "fix first, collect data later" strategy, but I'm still interested in some data at some point.