search for: armframelowering

Hello LLVMDev, I've encountered what looks like a bug in LLVM 2.9, it doesn't appear to be fixed in 3.0 either. The problem occurs in function ARMFrameLowering.cpp:processFunctionBeforeCalleeSavedScan. There's a circular dependency in setting the variable BigStack and AFI->setHashStackFrame(true). The expression which initializes BigStack calls estimateRSSStackSizeLimit which in turn checks AFI->hasStackFrame(). Unfortunately setHasStackFrame(tr...

...other check AFI->hasStackFrame() which seems wrong. The function should assume the function has a stack frame, because its entire function is to estimate its size! It looks like that check has been copy-pasted from elsewhere in the file. Anton, would you agree with this? I haven't looked at ARMFrameLowering before. Cheers, James -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Anton Korobeynikov Sent: 05 December 2011 11:11 To: Alok Manchanda Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] bug in ARMFrameLowering.cpp:processFunct...

Hello Alok, > I fixed this by performing the CanEliminateFrame and > RegInfo->cannotEliminateFrame checks before the call to > estimateRSSStackSizeLimit, since these values are available before BigStack > is initialized. Does that sound reasonable? I’ve attached a patch with my > change. Will you please provide a testcase which reproduces the problem? Thanks! -- With best

...s not belong to the low register set (r0-r7). After a bit of digging, the following patch seems to take care of it. Basically what happens is: - the C function in the example doesn't have any local to save - the only spilled register is LR - the Prolog/Epilog Inserted calls the target specific ARMFrameLowering::processFunctionBeforeCalleeSavedScan - at this point the we need to fix the fact that SP would not be EABI compliant because only 1 register has been spilled so far - inside processFunctionBeforeCalleeSavedScan, there a check: if TargetAlign == 8 && (NumGPRSpills & 1) then we align the...

...> to compile and run it now. We have done the similar work[1] on this topic by gcc and we have start migrate our platform to LLVM. In my experience, you need to take care the follow part: * ARMBaseRegisterInfo::getRegPressureLimit * ARMBaseRegisterInfo::getRawAllocationOrder * CalleeSavedRegs * ARMFrameLowering::emitPrologue [1] Doubling the Number of Registers on ARM Processors http://aces.snu.ac.kr/interact-16/papers/interact-16-paper-1.pdf

I almost change all the instruction formats. It was a huge work. I am going to compile and run it now. Best Regards, A. Yazdanbakhsh >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> PhD. Student School of Electrical and Computer Engineering University of Wisconsin-Madison E-mail: yazdanbakhsh

...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 > > target datalayout = > "e-p:32:32:32-i1:8:32-i8:8:32-i16:16:32-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v12...

Hi Tim, Thank you for your reply. Actually, I already played with various target triples including what sys::getProcessTriple() returns when I tried to compile it on a Raspberry Pi 3 device. Yes, changing the triple to armv7-unknown-linux-gnueabi changes the emitted return instruction to 'bx lr'. But this is not the issue. Let me describe it based on an example I prepared to demonstrate

...> 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/l...

..._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 > > > > target datalayout = > > > "e-p:32:32:32-i1:8:32-i8:8:32-i16:16:32-i32:32:32-i64...

I wonder if any body tried implementing morestack for ARM. [ARMFrameLowering.cpp file does not have implementation for adjustForSegmentedStacks method] More I study more I get lost, Any help or input is highly appreciated. TIA, Amit -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20...

...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 target datalayout = "e-p:32:32:32-i1:8:32-i8:8:32-i16:16:32-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:64:128-a0:0:32-n32-S64" ta...