registers pushed on stack when not needed

Wouldn't

pop {r3, r4, r5, pc}
bx r2

return from the current function (by virtue of the fact that the stacked lr gets popped into the pc) and so the bx r2 would never get executed?

Also - I'm not sure if all functions necessarily save/restore r3-r5 or if what they save/restore depends on their automatic/stack variables? You might want to check the relevant [E]ABI.

Hope this helps

r0 - r3 are caller-saved registers. They are not necessary to save/restore. In this case, "save/restore r3" is to make sure the stack is 8-bytes aligned.

@TM you're absolutely right,
the correct sequence I would have expected is

pop {r3, r4, r5}
bx r2
pop pc

Wouldn't this save up 12 bytes of stacked registers?

Errata corrige:
pop {r3, r4, r5}
--- bx r2
+++ blx r2
pop pc

@TM
I'm compiling with the above described gcc options on a arm-none-eabi- target toolchain. (the one provided in this website).
Could you point me with some reference on the correct EABI doc to read?
I really need to understand this, as I cannot afford losing 16 bytes of stack for each nested call by default. My code *can* end up using recursion in which case I need to be extremely efficient on stack consumption.
Regards

As Zhenqiang explained, r0-r3 registers are caller-saved which in your case means if you don't save them before doing the blx they might get corrupted by the called routine. This is explained in the [AAPCS] in section 5.1.1 named "Core registers".

[AAPCS] http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf

Best regards.

@Thomas and Zhenqiang
I am afraid I'm not understanding the insights of your answer. What I do not get, in particular, is why should the compiler care about restoring registers if those are not needed below the BLX?

If you go like this

PUSH {R3, R4, R5, LR}
...
BLX R2
POP {r3, r4, r5, pc}

you are restoring R3, R4 and R5 to their value before leaving the function. But there is absolutely no need for this; the last POP will load the PC with stored LR value, hence throwing me back to the callee function.
If you consider the following different sequence of assembly instructions

PUSH {R3, R4, R5, LR}
...
POP {R3, R4, R5, LR}
BX R2

it should not bring any corruption in.

The link register will remain the same and will throw me back outside the function from the inner subroutine without stacking any registers.
Can you build a counter example to show how the last instruction in the original asm sequence (22: bd38 pop {r3, r4, r5, pc}) is anyhow required (aside PC that is, in that sequence required to jump back outside)?

Edit:
The last asm sequence IS required, but could be done before calling the BX R2 hence saving stack space

> Could you point me with some reference on the correct EABI doc to read?

Thomas Preud'homme (thomas-preudhomme) in comment #6 has linked to the relevant doc.

> My code *can* end up using recursion

Slightly off topic from your original/core question but this may not be a good idea in an embedded system.
After all embedded/critical systems coding standards such as MISRA-C prohibit recursion for a reason. :-)
If you were not using recursion would it render your original/core question moot?

> this may not be a good idea in an embedded system
I'm aware of this. Recursion is under control and cannot be avoided due to the nature itself of the task that I need to perform, but is limited to well defined cases and depth is restrained.

I've seen the doc. Pretty much insightful, but what do you think about this sequence ?

PUSH {R3, R4, R5, LR}
...
POP {R3, R4, R5, LR}
BX R2

Does it make sense to you?

> PUSH {R3, R4, R5, LR}
> ...
> POP {R3, R4, R5, LR}
> BX R2
This IS tail call merge, which is a standard optimization in GCC. However, the GCC version you used does not merge tail call in case of indirect call due to some conservative consideration.

The good news is that the next major release should enable this, and here is what I got with a new a version:

        pop {r4, lr}
        ldr r3, [r3]
        bx r3

Thanks,
Joey

>> PUSH {R3, R4, R5, LR}
>> ...
>> POP {R3, R4, R5, LR}
>> BX R2
>
>This IS tail call merge, which is a standard optimization in GCC. However, the GCC version you used does not merge tail call in case of >indirect call due to some conservative consideration.
>
>The good news is that the next major release should enable this, and here is what I got with a new a version:
>
> pop {r4, lr}
> ldr r3, [r3]
> bx r3

Thanks it's so unfortunate I did not know the appropriate name for what I was asking. So it is the "tail call merge".
Can you provide details on which next major release you are using and how to obtain it?
No complains with compiling toolchains from scratch if that's what is needed.
Hopefully this information could solve my problem.
R

Next release including this optimization will be 4.9 targeting end of 2014.

On Tue, Sep 2, 2014 at 8:13 PM, InuY4sha <
<email address hidden>> wrote:

> Question #253914 on GCC ARM Embedded changed:
> https://answers.launchpad.net/gcc-arm-embedded/+question/253914
>
> Status: Answered => Open
>
> InuY4sha is still having a problem:
> >> PUSH {R3, R4, R5, LR}
> >> ...
> >> POP {R3, R4, R5, LR}
> >> BX R2
> >
> >This IS tail call merge, which is a standard optimization in GCC.
> However, the GCC version you used does not merge tail call in case of
> >indirect call due to some conservative consideration.
> >
> >The good news is that the next major release should enable this, and here
> is what I got with a new a version:
> >
> > pop {r4, lr}
> > ldr r3, [r3]
> > bx r3
>
> Thanks it's so unfortunate I did not know the appropriate name for what I
> was asking. So it is the "tail call merge".
> Can you provide details on which next major release you are using and how
> to obtain it?
> No complains with compiling toolchains from scratch if that's what is
> needed.
> Hopefully this information could solve my problem.
> R
>
> --
> You received this question notification because you are an answer
> contact for GCC ARM Embedded.
>