search for: tpop_ret

...n !25 DBG_VALUE 2, 0, !17, !18, debug-location !27 DBG_VALUE debug-use %r0, debug-use _, !16, !18, debug-location !26 tCMPi8 %r0, 2, 14, _, implicit-def %cpsr, debug-location !32 t2IT 11, 28, implicit-def %itstate %r0 = tMOVi8 _, 1, 11, %cpsr, implicit %r0, implicit %itstate tPOP_RET 11, %cpsr, def %r4, def %r6, def %r7, def %pc, implicit %r0, implicit %r4, implicit killed %itstate, debug-location !44 %r1 = t2MOVi 2, 14, _, _ t2B %bb.3.for.body, 14, _ Note that a terminator tPOP_RET is before a non-terminator t2MOVi. The command line to produce this is as follows: llc...

> The right way to update the CFG very much depends on how you're > transforming it. I would like to export the CFG for control flow checking. Theoretically, it should be possible for a compiler to know every target of every control flow instruction, except for computed targets that are not known at compile-time. When a machine basic block is split between two branches, as shown below:

...MachineBasicBlock &MBB) const { + MachineBasicBlock &MBB) const { MachineBasicBlock::iterator MBBI = MBB.getLastNonDebugInstr(); assert((MBBI->getOpcode() == ARM::tBX_RET || - MBBI->getOpcode() == ARM::tPOP_RET) && - "Can only insert epilog into returning blocks"); + MBBI->getOpcode() == ARM::tPOP_RET || + MBBI->getOpcode() == ARM::TCRETURNri) + && "Can only insert epilog into returning blocks " + "and tail calls...

...ed1> = tADDhirr %SP<tied0>, %vreg0<kill>, pred:14, pred:%noreg; tGPR:%vreg0 %vreg1<def> = tLDRpci <cp#1>, pred:14, pred:%noreg; tGPR:%vreg1 %SP<def,tied1> = tADDhirr %SP<tied0>, %vreg1<kill>, pred:14, pred:%noreg; tGPR:%vreg1 tPOP_RET pred:14, pred:%noreg, %R4<def>, %PC<def>, %SP<imp-def>, %SP<imp-use> # End machine code for function main. On Thumb you can save/restore a register without having to use a spill slot, so the scavenger won't run into problems, but if a target had to spill, we would...

...= tADDhirr %SP<tied0>, %vreg0<kill>, pred:14, pred:%noreg; tGPR:%vreg0 > %vreg1<def> = tLDRpci <cp#1>, pred:14, pred:%noreg; tGPR:%vreg1 > %SP<def,tied1> = tADDhirr %SP<tied0>, %vreg1<kill>, pred:14, pred:%noreg; tGPR:%vreg1 > tPOP_RET pred:14, pred:%noreg, %R4<def>, %PC<def>, %SP<imp-def>, %SP<imp-use> > > # End machine code for function main. > > > On Thumb you can save/restore a register without having to use a spill slot, so the scavenger won't run into problems, but if a target h...

...%vreg0<kill>, pred:14, >> pred:%noreg; tGPR:%vreg0 >> %vreg1<def> = tLDRpci <cp#1>, pred:14, pred:%noreg; tGPR:%vreg1 >> %SP<def,tied1> = tADDhirr %SP<tied0>, %vreg1<kill>, pred:14, >> pred:%noreg; tGPR:%vreg1 >> tPOP_RET pred:14, pred:%noreg, %R4<def>, %PC<def>, >> %SP<imp-def>, %SP<imp-use> >> >> # End machine code for function main. >> >> >> On Thumb you can save/restore a register without having to use a spill >> slot, so the scavenger won't r...

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

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: