similar to: [LLVMdev] Prolog/Epilog Insertion Question

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

Consider this example: --- ex.ll --- declare void @bar() ; Function Attrs: nounwind optsize define void @main() { entry: %hin = alloca [256 x i32], align 4 %xin = alloca [256 x i32], align 4 call void @bar() ret void } ------------- Freshly built llc: llc -O2 -march=x86 < ex.ll -print-before-all # *** IR Dump Before Prologue/Epilogue Insertion & Frame Finalization ***: #

The code has changed a lot over the years. Looks like at some point of time the assumption was broken. calculateCallsInformation() may have eliminated the pseudo set up instructions already. // If call frames are not being included as part of the stack frame, and

Thanks, I'll look into that. Still, the case where the function does not call anything remains---in such a situation there are no ADJCALLSTACK pseudos, so regardless of what that function you pointed at does, there won't be any target-independent information about the SP adjustment by the time the frame index elimination runs. Would it make sense to have ADJCALLSTACK pseudos every

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

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

Hi All, When seeing the title "Prolog/Epilog Code Insertion", I'd expect something about XXXFrameLowering.cpp (particular about emitPrologue/emitEpilogue). But the document [1] is about unwind. Is it placed at the right place/section? Thanks. [1] http://llvm.org/docs/CodeGenerator.html#prolog-epilog-code-insertion Regards, chenwj -- Wei-Ren Chen (陳韋任) Homepage:

On Mon, Jul 23, 2007 at 02:19:38PM +0200, Florian Brandner wrote: > hi, > > i know it took a while, but here is a patch that adds a list of source > values to machine instructions. Cool! > i've testet all this for our backend only, which is not public. i do not > know how much has to be done to integrate this with the other, e.g., the > x86, targets. does any of the

Hi, My backend (based on version 3.8) was hanging in an infinite loop in the Prolog/Epilog Inserter. After investigation, it appears that it was looping in the first level loop of the PEI::replaceFrameIndices() method: processing the second instruction of the block again and again... This loop never exits because the iterator is 'skipped backward' under some condition in the middle of

Dan Gohman wrote: > I tried out your patch on x86 and it didn't appear to need any special changes. it might be needed to look at the addressing modes of a load/store to get the right offset. but i think it should work, if the lowering does not rewrite loads/stores into custom DAG nodes. > For the [??], it looks like the IsFrameIndex isn't getting set for the first > instruction

I am new to the LLVM, and need some help with this points. 1. how can we add special code for the Prolog/Epilog for some certain functions, this should be done with machinefunction pass, rt? 2. Basically, I want to get the function stack frame, that is the size and the initial position. I found int64_t llvm::MachineFrameInfo::getObjectSize ( int *ObjectIdx* ) const[inline] This method is

Hello, I'd like to upstream our work over the time which the community would benefit from. This is a part of effort toward minimizing code size presented in here <https://llvm.org/devmtg/2020-02-23/slides/Kyungwoo-GlobalMachineOutlinerForThinLTO.pdf>. In particular, this RFC is about optimizing prolog and epilog for size. *Homogeneous Prolog and Epilog for Size Optimization, D76570

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 Vedant, Thanks for your interest and comment. Size-optimization improves page-faults and a start-up time for a large application, which this enabling also followed. Even though I didn't see a large regression/complaint on a CPU-bound case, which is not a typical case for mobile workload, I wanted to be precautious of enabling it by default. However, as with default outlining case, I

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, i know it took a while, but here is a patch that adds a list of source values to machine instructions. i modified the DAGISelEmiter to automatically catch regular loads/stores. custom instructions and loads/stores rewritten by the lowering pass are not automatically captured. during the instruction selection a source value operand is added to the DAG for patterns matching a load/store.

Hi, Chris Lattner wrote: > In the 2.3 release, we included a list of the major LLVM API changes. If you > are working on upgrading your code from 2.3 to 2.4, I'd appreciate it if you > could compile a list of the major stumbling blocks you have, so that others > can benefit from your experience. Please send any info to the list, thanks! No major stumbling blocks during our

In the 2.3 release, we included a list of the major LLVM API changes. If you are working on upgrading your code from 2.3 to 2.4, I'd appreciate it if you could compile a list of the major stumbling blocks you have, so that others can benefit from your experience. Please send any info to the list, thanks! -Chris

This is a feature I’m considering for the LLVM backend. Feel free to provide input in the following PR. llvm.org/pr19267 - Add a feature to clobber non-callee-save regs in the prolog. I’m copying llvm-dev because it seems like something that others must have already done or at least thought about at some point. -Andy