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

Andrea Mucignat andrea at nestlabs.com
Tue Oct 15 10:15:02 PDT 2013


Umesh,

>From Target/ARM/ARMRegisterInfo.td, it looks like FP for Thumb should be r7
instead of r11.

// Register classes.
//
// pc  == Program Counter
// lr  == Link Register
// sp  == Stack Pointer
// r12 == ip (scratch)
// r7  == Frame Pointer (thumb-style backtraces)
// r9  == May be reserved as Thread Register
// r11 == Frame Pointer (arm-style backtraces)
// r10 == Stack Limit

Regardless, I'm compiling with -fomit-frame-pointer, so it should not
really matter, right?

Andrea



On Tue, Oct 15, 2013 at 8:33 AM, Umesh Kalappa <umesh.kalappa0 at gmail.com>wrote:

> Hi andrea,
> R11 treated as  frame pointer at arm backend , which is fixed again .
>
> Thanks
> Umesh
>
>
> On Tuesday, October 15, 2013, Andrea Mucignat <andrea at nestlabs.com> wrote:
> > Umesh,
> > Makes some sort of sense to me, OTOH:
> > If instead of choosing r11 as a "dummy" to align the stack we had chosen
> some other register in the range r0-r7 then we could have emitted the PUSH
> encoding T1 (2 bytes opcode) as opposed to the encoding T2 (which is a 4
> bytes opcode).
> > A
> >
> > On Tue, Oct 15, 2013 at 2:59 AM, Umesh Kalappa <umesh.kalappa0 at gmail.com>
> wrote:
> >
> > Hi Andrea,
> >
> > That is because the LR is the  fixed register as per the
> >
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042e/IHI0042E_aapcs.pdf
> > and out_char() function is not  the leaf function ,Hence compiler
> > tends to save and restore the  LR  and the save  and restore of
> > register r11 is to align stack for 8 bytes as per ARM EABI.
> >
> >
> >
> > Thanks
> >
> > ~Umesh
> >
> >
> > On Tuesday, October 15, 2013, Umesh Kalappa <umesh.kalappa0 at gmail.com>
> wrote:
> >> ---------- Forwarded message ----------
> >> From: Andrea Mucignat <andrea at nestlabs.com>
> >> Date: Tue, Oct 15, 2013 at 7:05 AM
> >> Subject: [LLVMdev] Unwanted push/pop on Cortex-M.
> >> To: llvmdev at cs.uiuc.edu
> >>
> >>
> >> Hi,
> >>
> >> I have this code:
> >>
> >> void platform_putchar(int, char);
> >> void out_char( char ch );
> >>
> >> void out_char( char ch )
> >> {
> >>     platform_putchar (0, ch);
> >> }
> >>
> >> I'm compiling with the following clang invocation:
> >>
> >> $
> /usr/local/vendor/toolchains/llvm/3.3/armv7m/bin/armv7m-none-eabi-clang
> >> -mcpu=cortex-m4 -mfloat-abi=soft -mthumb -nostdinc -ffreestanding
> >> -ffunction-sections -fdata-sections -fno-exceptions -fno-rtti
> >> -fomit-frame-pointer -momit-leaf-frame-pointer -nostdinc -v -Os -S -o
> >> a.s a.c
> >> vendor-clang version 3.3 (tags/RELEASE_33/final) (based on LLVM 3.3)
> >> Target: armv7m-none--eabi
> >> Thread model: posix
> >>
>  "/usr/local/vendor-20130805-b8d59d2/toolchains/llvm/3.3/armv7m/bin/armv7m-none-eabi-clang"
> >> -cc1 -triple thumbv7em-none--eabi -S -disable-free -main-file-name a.c
> >> -mrelocation-model static -fmath-errno -mconstructor-aliases
> >> -target-abi aapcs -target-cpu cortex-m4 -msoft-float -mfloat-abi soft
> >> -target-feature +soft-float -target-feature +soft-float-abi
> >> -target-feature -neon -target-linker-version 2.22
> >> -momit-leaf-frame-pointer -v -ffunction-sections -fdata-sections
> >> -coverage-file /tmp/a.s -nostdsysteminc -nobuiltininc -resource-dir
> >>
> /usr/local/vendor-20130805-b8d59d2/toolchains/llvm/3.3/armv7m/bin/../lib/clang/3.3
> >> -Os -fno-dwarf-directory-asm -fdebug-compilation-dir /tmp
> >> -ferror-limit 19 -fmessage-length 207 -ffreestanding -mstackrealign
> >> -fno-rtti -fno-signed-char -fobjc-runtime=gcc
> >> -fobjc-default-synthesize-properties -fdiagnostics-show-option
> >> -fcolor-diagnostics -backend-option -vectorize-loops -o a.s -x c a.c
> >> clang -cc1 version 3.3 based upon LLVM 3.3 default target
> armv7m-none-eabi
> >> #include "..." search starts here:
> >> End of search list.
> >>
> >> $ cat a.s
> >>     .syntax unified
> >>     .eabi_attribute 6, 10
> >>     .eabi_attribute 9, 2
> >>     .eabi_attribute 10, 5
> >>     .fpu vfpv4
> >>     .eabi_attribute 20, 1
> >>     .eabi_attribute 21, 1
> >>     .eabi_attribute 23, 3
> >>     .eabi_attribute 24, 1
> >>     .eabi_attribute 25, 1
> >>     .eabi_attribute 44, 1
> >>     .file    "a.c"
> >>     .section    .text.out_char,"ax",%progbits
> >>     .globl    out_char
> >>     .align    2
> >>     .type    out_char,%function
> >>     .code    16
> >>     .thumb_func
> >> out_char:
> >>     push.w    {r11, lr}
> >>     mov    r1, r0
> >>     movs    r0, #0
> >>     bl    platform_putchar
> >>     pop.w    {r11, pc}
> >> .Ltmp0:
> >>     .size    out_char, .Ltmp0-out_char
> >>
> >> The one question I have is:
> >> why can't this out_char function be compiled into:
> >>
> >> out_char:
> >>     mov r1, r0
> >>     mov r0, #0
> >>     bl platform_putchar
> >>     bx lr
> >>
> >> What's the clang/llvm module responsible for generating the prologue
> >> and epilogue for this function?
> >> I looked into CodeGen/PrologEpilogInserter, ARMFrameLowering.cpp
> >> Thumb1FrameLowering.cpp but it's not 100% clear how the code gen
> >> decides what the stack frame look like.
> >>
> >> Here's the -emit-llvm output
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131015/a1662407/attachment.html>


More information about the llvm-dev mailing list