This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

arm-none-eabi-gcc uses floating point register to backup GPR in case of -O2 option

arm-none-eabi-gcc version:
(GNU Arm Embedded Toolchain 9-2020-q2-update) 9.3.1 20200408 (release)

When using following compiler flags:
-O2 -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16

the compiler use floating point register s16 as cache for general pur pose integral registers of Cortex M4 core.

This is done even though the function doesn't do explicit floating point operations.
I use RTOS for which FPU usage is restricted to certain tasks/threads.
In that case task executing the function fails with UsageFault/NOCP.

This happens when O2 optimization is used, in case of lower optimization levels problem doesn't occur.
Is that maybe possible to prohibit compiler from that kind of agressive optimization (using FPU registers to store GPR data)?

Some disassembler indication of the issue:

static void fun(void *args)
{
100149cc: e92d 4ff0 stmdb sp!, {r4, r5, r6, r7, r8, r9, sl, fp, lr}
# d8 floating point register pushed
100149d0: ed2d 8b02 vpush {d8}
100149d4: 4d77 ldr r5, [pc, #476] ; (10014bb4 <fun+0x1e8>)
# r4 being loaded with a static variable pointer (to be used later in call to fun7)
100149d6: 4c78 ldr r4, [pc, #480] ; (10014bb8 <fun+0x1ec>)
...
100149fa: f001 fd3b bl 10016474 <fun3>
# the pointer been backed up in s16?
100149fe: ee08 4a10 vmov s16, r4
10014a02: f000 ff9b bl 1001593c <fun4>
10014a06: f000 fb87 bl 10015118 <fun5>
10014a0a: f240 5305 movw r3, #1285 ; 0x505
10014a0e: 2205 movs r2, #5
10014a10: f990 1010 ldrsb.w r1, [r0, #16]
10014a14: 7482 strb r2, [r0, #18]
10014a16: 9105 str r1, [sp, #20]
10014a18: 8a01 ldrh r1, [r0, #16]
10014a1a: 8203 strh r3, [r0, #16]
10014a1c: 9106 str r1, [sp, #24]
10014a1e: 4605 mov r5, r0
10014a20: f001 f816 bl 10015a50 <fun6>
10014a24: f06f 4100 mvn.w r1, #2147483648 ; 0x80000000
# previously backed up pointer being restored to GPR
10014a28: ee18 0a10 vmov r0, s16
# the pointer being used in function call
10014a2c: f7fd ff46 bl 100128bc <fun7>

I'll appreciate if someone help me with this issue.