similar to: [LLVMdev] Attention: About to Break SystemZ and possibly other Back Ends

> 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 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

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

Hello, it seems the Prolog/Epilog insertion does not correctly align stack for me. Consider the PEI::calculateFrameObjectOffsets method. It only aligns the stack if FFI->hasCalls() is true. The only place where MachineFrameInfo::setHasCalls is invoked is PEI::saveCallerSavedRegisters and the value 'true' is only passed when there are instructions with opcodes equal

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

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 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

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

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

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.

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 <

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

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 found a difference between Clang and GCC in alias handling. This was with a benchmark where Clang was considerably slower, and in a hot function which does many more loads from the same address due to stores between the uses. In other words, a value is loaded and used, another value is stored, and then the first value is loaded once again before its second use. This happens many times,

> > I would say that GCC is wrong and should also have a version where a > could be equal to b. There is no restrict keyword, so they could be > equal. > This was between a/b and c, not between a and b. Could you explain your opinion a bit more in detail, please? /Jonas > Cheers, > > Matthieu > > Le jeu. 20 sept. 2018 à 16:56, Jonas Paulsson via llvm-dev >

Running on x86-64 linux: FAIL: test/CodeGen/X86/vec_ins_extract.ll Failed with exit(1) at line 1 while running: llvm-as < test/CodeGen/X86/vec_ins_extract.ll | opt -scalarrepl -instcombine | llc -march=x86 -mcpu=yonah | not grep sub.*esp subl $16, %esp subl $16, %esp subl $16, %esp subl $16, %esp child process exited abnormally FAIL:

Thanks, Ralph, this line worked well :) Here it is, my first patch to LLVM :) I've changed all allocation_order_begin() and allocation_order_end() methods to take const MachineFunction &MF as a parameter. I also added const version of MachineFunction::getInfo<Ty>() method. And I changed three static hasFP() functions to take const reference to MachineFunction. While doing this

Mehdi, I am perusing the 3.8 trunk sources, and don’t find evidence where I would expect it for LLVM “downgrading” a function’s calling convention. PrologEpilogEmitter() { “CodeGen/” ... TFI->determineCalleeSaves() { “Target/XYZ/” TargetFrameLowering::determineCalleeSaves() { “CodeGen/” Return <<< some object derived