search for: replaceframeindices

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 the loop (see yellow highlighted line). I understand the rationale explained in the first comment, but I don'...

...th 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: ---------------------------------------- void PEI::replaceFrameIndices(MachineBasicBlock *BB, MachineFunction &Fn, int &SPAdj) { const TargetMachine &TM = Fn.getTarget(); assert(TM.getRegisterInfo()...

...ode 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 Parzyszek <kparzysz at codeaurora.org> wrote: > 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 bas...

...de 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 Parzyszek > <kparzysz at codeaurora.org <mailto:kparzysz at codeaurora.org>> wrote: > >> Hi All, >> I'm dealing with a problem where the spill/restore instructions >> inserted durin...

...CALLSTACKDOWN64. >> 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 Parzyszek >> <kparzysz at codeaurora.org <mailto:kparzysz at codeaurora.org>> wrote: >> >>> Hi All, >>> I'm dealing with a problem where the spill/rest...

I've been looking through the code for pologue/epilogoue generation and noticed this oddity: void PEI::replaceFrameIndices(MachineFunction &Fn) { [...] for (MachineBasicBlock::iterator I = BB->begin(); I != BB->end(); ) { [...] if (I->getOpcode() == FrameSetupOpcode || I->getOpcode() == FrameDestroyOpcode) { [...] } else { [...] for (unsigned i...

...>>> 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 Parzyszek >>> <kparzysz at codeaurora.org <mailto:kparzysz at codeaurora.org> >>> <mailto:kparzysz at codeaurora.org>> wrote: >>> >&g...

...d machine code for Insert(). 4) Then I get the following assertion: llc: /opt/llvm/lib/CodeGen/RegisterScavenging.cpp:223: void llvm::RegScavenger::forward(): Assertion `isUsed(Reg) && "Using an undefined register!"' failed. It is triggered by PrologEpilogInserter::replaceFrameIndices() function. The undefined register is the LR register. If I dump the function at this point I see the following (the instruction tiggering the assetion is marked by ***): # Machine code for Insert(): <fi#0>: size is 4 bytes, alignment is 4 bytes, at location [SP-4] Live Ins: R0 in VR#...