search for: emitepilogu

...>, 0, %RDI<kill>, >>> %RAX<imp-def,dead>, %RDI<imp-def,dead>, %RSP<imp-use>, ... >> >> Odd. I thought TCReturn was being lowered. At any rate can you file >> a bug with the .ll file that causes this? > > It should be getting lowered in emitEpilogue. Must be a bug somewhere. > For some reason I am getting this error even when I only have an empty 'main' function. So I couldn't create .ll file reproducing it and I have to debug myself. The function causing the problem is stub created in JIT::runFunction: Function *Stub =...

...RETURNri64 %RAX<kill>, 0, %RDI<kill>, >> %RAX<imp-def,dead>, %RDI<imp-def,dead>, %RSP<imp-use>, ... > > Odd. I thought TCReturn was being lowered. At any rate can you > file a bug with the .ll file that causes this? It should be getting lowered in emitEpilogue. Must be a bug somewhere.

...>>>> %RAX<imp-def,dead>, %RDI<imp-def,dead>, %RSP<imp-use>, ... >>> >>> Odd. I thought TCReturn was being lowered. At any rate can you >>> file a bug with the .ll file that causes this? >> >> It should be getting lowered in emitEpilogue. Must be a bug >> somewhere. >> > > > For some reason I am getting this error even when I only have an > empty 'main' function. So I couldn't create .ll file reproducing it > and I have to debug myself. > > The function causing the problem is stu...

...RDI<kill>, %RAX<imp-def,dead>, %RDI<imp-def,dead>, %RSP<imp-use>, ... >>>> >>>> Odd. I thought TCReturn was being lowered. At any rate can you file a bug with the .ll file that causes this? >>> >>> It should be getting lowered in emitEpilogue. Must be a bug somewhere. >>> >> >> >> For some reason I am getting this error even when I only have an empty 'main' function. So I couldn't create .ll file reproducing it and I have to debug myself. >> >> The function causing the problem is...

...;> >>> The function causing the problem is stub created in >>> JIT::runFunction: Function *Stub = Function::Create(STy, >>> Function::InternalLinkage, "" ... >>> >>> Here is the log of machine instructions before and after >>> emitEpilogue for this function: >>> * PEI::insertPrologEpilogCode: === >> before emitEpilogue >>> - insn: PUSH64r %RBP<kill>, %RSP<imp-def>, %RSP<imp-use> >>> - insn: PROLOG_LABEL <MCSym=.Ltmp2> >>> - insn: %RBP<def> = MOV64rr %RSP >&gt...

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: https://people.cs.nctu.edu.tw/~chenwj -------------- next part -------------- An...

> -----Original Message----- > From: mbraun at apple.com [mailto:mbraun at apple.com] > Sent: Friday, February 17, 2017 3:15 PM > To: Alex Bradbury > Cc: llvm-dev; Adrian Prantl; Eric Christopher; Robinson, Paul > Subject: Re: [llvm-dev] RFC: Setting MachineInstr flags through > storeRegToStackSlot > > Can someone familiar with debug info comment on whether it matters

...ttachment.bin> -------------- next part -------------- Index: Thumb1FrameLowering.cpp =================================================================== --- Thumb1FrameLowering.cpp (Revision 225589) +++ Thumb1FrameLowering.cpp (Arbeitskopie) @@ -323,11 +323,18 @@ } void Thumb1FrameLowering::emitEpilogue(MachineFunction &MF, - MachineBasicBlock &MBB) const { + MachineBasicBlock &MBB) const { MachineBasicBlock::iterator MBBI = MBB.getLastNonDebugInstr(); assert((MBBI->getOpcode() == ARM::tBX_RET || -...

...ed" by the current thread. I'm not sure where the best place in the LLVM architecture to do this is. As I currently understand it, the concept of a stack frame appears pretty late in target code generation. I've hacked in a hook for this in X86FrameLowering.cpp in the emitPrologue and emitEpilogue methods. Is there a cleaner way I can do this? Is there a way I can subclass the X86 code generator to "hook" those two methods and insert my instrumentation? Is there something I'm missing with runOnMachineFunction? Thank you, Andrew -------------- next part -------------- An HTM...

...er I > couldn't figure out how to implement some stuff. > I'd appreciate your help with these. > > First thing is return address saving. To do that, first I have to copy it to > a general purpose register. I have no idea how to find an unused gpr > register in emitPrologue/emitEpilogue. I've noticed that in other backends > RegScavenger is used for that purpose, but not from inside of those methods. > So my question is how could I get an unused register from inside of these > methods? Do you have an API specified register where the variable is passed? If so, it is...

...to write down names. I am interested in getting the ARM llc backend to emit/work with dwarf unwind tables and use those with llvm-gcc's generic c++ exception handling mechanism. A large part of this will also benefit ARM's eabi way of handling unwinding. A cursory glance at ARMFrameInfo::emitEpilogue() seems to indicate that nothing has been implemented yet. I am willing to invest some time on this but do not want to step on anybody's toes. Has anybody started working on this already? Robert

Hello, I want to find information/documentation on how reorganize stack frame (add other information, etc.) & how add new calling convention into ARM backend? I think it is needed to modify lowering of CALL, RET & FORMAL_ARGUMENT instruction, and also to modify emitPrologue & emitEpilogue functions. What are the others things to modify in order to realize my experimentation? Is it the best way to do it? Thanks in advance. Mikaël. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/2...

...a backend for our CPU. However I couldn't figure out how to implement some stuff. I'd appreciate your help with these. First thing is return address saving. To do that, first I have to copy it to a general purpose register. I have no idea how to find an unused gpr register in emitPrologue/emitEpilogue. I've noticed that in other backends RegScavenger is used for that purpose, but not from inside of those methods. So my question is how could I get an unused register from inside of these methods? And my second problem is with returning structures by value. ABI says that aggregates up to 32by...

Hi all, I've been working for some time now on a backend for our CPU. However I couldn't figure out how to implement some stuff. I'd appreciate your help with these. First thing is return address -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100415/989f532c/attachment.html>

...ck::iterator MBBI; <-- points to where the epilogue would be inserted if (MBBI != MBB.begin() ? MBBI->getPrevNode()->isCall() : MBB.getPrevNode()->back().isCall()) { // insert NOP } However, this did not work because at the stage where I am trying to do this (in X86FrameLowering::emitEpilogue), the MBBs look like this: BB0: ... CALL ... <-- call I am trying to detect EH_LABEL ... <--| these two get eliminated in the final JMP <BB1> <--| emitted code. BB1: <-- the MBB RET <-- MBBI points here So the business of finding the previous...

...eturn When generating the epilog the two operands of the the tc_return machine instruction are used to emit code that adjust the stackpointer and jumps to the tailcallee (either label or register). Like it is done for EH_RETURN. in X86RegisterInfo.cpp we would then have TargetRegisterInfo::emitEpilogue() { ... if (RetOpcode== X86::TC_RETURN){ if (isDynamicCallee(RetOpCode)) add esp {stack adjustment from tc_return} jmp {register operand of tc_return} } else add esp {stack adjustment from tc_return} jmp {targetfunction operand} } } resulting cod...

...ead. > > I'm not sure where the best place in the LLVM architecture to do this > is. As I currently understand it, the concept of a stack frame appears > pretty late in target code generation. I've hacked in a hook for this > in X86FrameLowering.cpp in the emitPrologue and emitEpilogue methods. > > Is there a cleaner way I can do this? Is there a way I can subclass > the X86 code generator to "hook" those two methods and insert my > instrumentation? Is there something I'm missing with > runOnMachineFunction? I'm stepping beyond what I know a...

...hread. > > I'm not sure where the best place in the LLVM architecture to do this is. > As I currently understand it, the concept of a stack frame appears pretty > late in target code generation. I've hacked in a hook for this in > X86FrameLowering.cpp in the emitPrologue and emitEpilogue methods. > > Is there a cleaner way I can do this? Is there a way I can subclass the > X86 code generator to "hook" those two methods and insert my > instrumentation? Is there something I'm missing with runOnMachineFunction? > > > I'm stepping beyond what I...

## Problem description One of the responsibilities of a target's implementation of TargetFrameLowering::emitPrologue is to set the frame pointer (if needed). Typically, the frame pointer will be stored to the stack just like the other callee-saved registers, and emitPrologue must insert the instruction to change its value after it was stored to the stack. Mips does this by looking at the

...out how to implement some stuff. > > I'd appreciate your help with these. > > > > First thing is return address saving. To do that, first I have to copy it > to > > a general purpose register. I have no idea how to find an unused gpr > > register in emitPrologue/emitEpilogue. I've noticed that in other > backends > > RegScavenger is used for that purpose, but not from inside of those > methods. > > So my question is how could I get an unused register from inside of these > > methods? > > Do you have an API specified register where the...