similar to: [LLVMdev] Stack alignment problem

Hi, I have a problem getting a properly aligned stack for my LLVM backend. I've asked about this previously, but unfortunately only now could try the suggested solution. For reference, here's the original message from me: http://mail.cs.uiuc.edu/pipermail/llvmdev/2004-July/001388.html And here's reply from Chris: http://mail.cs.uiuc.edu/pipermail/llvmdev/2004-July/001390.html The

Hi, right at the moment, LLVM won't align the stack for leaf functions. So, if stack alignment is 8 bytes, and leaf function has 1 variable of 4 bytes, the size of frame will be computed as 4 bytes, making stack pointer inside function non-aligned. I've mentioned this before: http://lists.cs.uiuc.edu/pipermail/llvmdev/2005-March/003701.html but did not pursue the issue back then.

On Tue, 22 Mar 2005, Vladimir Prus wrote: > The PrologEpilogInserter.cpp file aligns the stack only if > MachineFrameInfo::hasCalls returns true, which happens only if the function > has "call frame setup instruction" which my backend does not generate. > Chris suggested adding explicit MachineFrameInfo::setHasCalls call, which I've > tried, but it does not help. The

Hi, Attached is a patch I'm testing. It changes how "MachineFrameInfo::HasCalls" is calculated. Basically, the way it's calculated now is in PEI. And it only looks for frame adjustments (or inline ASM) to determine if the function has a call or not. This way is much more accurate and occurs much sooner. But it breaks this test:

On Tuesday 22 March 2005 20:34, Chris Lattner wrote: > Can you explain the problem in more detail? Specifically the LLVM code > gneerator assumes that there is some alignment that the stack is required > to have as part of its ABI. For example, in X86 target machine, the stack > is 8-byte aligned on entry to function calls. > > What this means is that the frame info can assume

sorry, Just noticed that the diagrams have 'Destroy' & 'SetUp' the wrong way around! Robert ________________________________ From: llvmdev-bounces at cs.uiuc.edu [llvmdev-bounces at cs.uiuc.edu] on behalf of Robert Lytton [robert at xmos.com] Sent: 21 August 2013 18:34 To: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] PrescheduleNodesWithMultipleUses() causing failure in

Hi all, I am trying to write a pass where i am creating a clone of a function (the only difference being, the new function returns void , instead of any value). I am creating a new Function Type with a void return type (rest being the same as original function), and using this i am creating a new function body. Then, i clone the body of the old function into new function, but when ever i

Hi, I'm gonna try to give some feedback, but I have only been working with LLVM for a few days, so don't take what I'm saying without verifying :-) > BasicBlock *ProgSlicer::CloneBasicBlock(const BasicBlock *BB, > DenseMap<const Value*, Value*> &ValueMap, > const char *NameSuffix, Function *F) { > > BasicBlock

In ARM the stack should be 8 bytes aligned during function calls. A function that has at least one function call then has a stack size of 8 bytes. PEI::calculateFrameObjectOffsets corretly computes this correctly. The problem is that the alignment is computed before adding space for the call frame size. This is done in emitProlog. Currently the ARM backend has a bug in that it doesn't align

On Fri, 6 Oct 2006, [UTF-8] Rafael Esp?ndola wrote: > In ARM the stack should be 8 bytes aligned during function calls. A > function that has at least one function call then has a stack size of > 8 bytes. PEI::calculateFrameObjectOffsets corretly computes this > correctly. > > The problem is that the alignment is computed before adding space for > the call frame size. This is

Hi, I have reasoned through and believe the problem is with the PrescheduleNodesWithMultipleUses. Take the following DAG (arrow to predecessor): Destroy Destroy ^ ^ | | | | SetUp----->PredSU <-----SU ^ ^ ^ | | | | | | ----------- |

Hi Dale, yes it's just stack alignment. Unfortunately your patch doesn't make any difference. Thanks for thinking about this, Duncan. On Friday 27 June 2008 19:51:00 Dale Johannesen wrote: > On Jun 27, 2008, at 3:11 AMPDT, Duncan Sands wrote: > > FAIL: test/CodeGen/X86/vec_shuffle-10.ll > > Failed with exit(1) at line 3 > > while running: llvm-as <

> This sounds like the ADJCALLSTACK DOWN/UP 'instructions' around the call > aren't set right, or you have declared a SP offset. It doesn't look like > the ARM backend does this, so this is probably the problem. The ARM backend currently doesn't use a frame pointer. It uses the same technique of the PPC backend to avoid add/subs around calls. In the PPC backend we

On Jun 27, 2008, at 3:11 AMPDT, Duncan Sands wrote: > FAIL: test/CodeGen/X86/vec_shuffle-10.ll > Failed with exit(1) at line 3 > while running: llvm-as < test/CodeGen/X86/vec_shuffle-10.ll | llc - > march=x86 -mattr=+sse2 | not grep {sub.*esp} > subl $16, %esp > subl $16, %esp > child process exited abnormally Is the code actually loading and storing

yOn Wed, 23 Mar 2005, Vladimir Prus wrote: >> How is your target different here? Can you give an example of why this >> causes a problem? > > Here's the code which computes the hasCalls flag: > > bool HasCalls = false; > > for (MachineFunction::iterator BB = Fn.begin(), E = Fn.end(); BB != E; ++BB) > for (MachineBasicBlock::iterator I = BB->begin(); I

On Jun 30, 2008, at 9:25 AMPDT, Duncan Sands wrote: > Hi Dale, yes it's just stack alignment. Unfortunately > your patch doesn't make any difference. > > Thanks for thinking about this, > > Duncan. OK, the test is not quite right then. This doesn't happen on Darwin so I'm afraid you'll have to debug it. Perhaps testing for

Hi Dale, > OK, the test is not quite right then. This doesn't happen on Darwin > so I'm > afraid you'll have to debug it. Perhaps testing for > (RegInfo->needsStackRealignment(Fn) && > FFI->getObjectIndexEnd()!=0) > ? yes, that works - thanks! Since I have no idea what this is doing, is it ok if I leave it to you to commit it?

Hi I have brought everything together in this email. The problem ======== Take the following DAG (arrow to predecessor): SetUp2 SetUp1 ^ ^ | | | | Destroy2---->PredSU <----SU ^ ^ ^ | | | | | | ----------- | ---------

Hi All, I'm dealing with a problem where the spill/restore instructions inserted during scavenging span an adjustment of the SP/FP register. The result is that despite the base register (SP/FP) being changed between the spill and the restore, both store and load use the same immediate offset. I see code in the PEI (replaceFrameIndices) that is supposed to track the SP/FP adjustment:

CallFrameSetupOpcode is a pseudo opcode like X86::ADJCALLSTACKDOWN64. That means when the code is expected to be called before the pseudo instructions are eliminated. I don't know why it's not the case for you. A quick look at PEI code indicates the pseudo's should not have been removed at the time when replaceFrameIndices are run. Evan On Sep 25, 2013, at 8:57 AM, Krzysztof