[LLVMdev] [PATCH] Unwanted r11 in push/pop on Cortex-M.

[Renato Golin]

On 21 October 2013 01:06, Andrea Mucignat <andrea at nestlabs.com> wrote:

> The part I didn't like is that push/pop become 4 bytes instructions
> because the register that we picked to "align" the stack pointer does not
> belong to the low register set (r0-r7).
> After a bit of digging, the following patch seems to take care of it.
>

Hi Andrea,

This seems a valid intention, but, since you're in Thumb2 mode, it
shouldn't make much of a difference, except for code size. And even for
code size, you'd save four bytes per function on the binary, which is
normally not enough to warrant a change. I also believe that this was not
accidental (though I can't confirm), since using R7 for the stack pointer
would split the register bank and reduce the ability, for instance, to use
sequential registers to shuffle GPRs into Ds and Qs and vice-versa.

That said, if register pressure is low, or if you're not using VFP or NEON,
you could use R7 as the stack frame, even on Thumb2. This could be an
option, and even enabled by default when in -Oz mode, for instance.


The problem is that this "unspilled" register list starts with r11 (for
> reasons I'm not clear about)
>

I guess that's because it's always good to have the frame pointer saved on
each stack, to make it easier to unwind the stack while debugging, even
with high optimization levels. Someone with more contact with that part of
the code can chime in, but that seems pretty intentional, and it makes
sense, too.



> The part I'm not sure about is: what if r4-r7 are all spilled already, is
> the SP going to be aligned by some other routine later on (maybe by adding
> a "sub sp, sp, #4")?
>

I think you'd have to come up with a few tests on each possible problematic
case you can think of. If you end up implementing this, I think you'll need
a good set of test cases, so that we make sure the behaviour you want
doesn't leak to unwanted cases.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131021/67ac93f4/attachment.html>