[LLVMdev] Unwanted push/pop on Cortex-M.
Umesh Kalappa
umesh.kalappa0 at gmail.com
Tue Oct 15 08:33:14 PDT 2013
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/1c7cdab3/attachment.html>
More information about the llvm-dev
mailing list