search for: instr_iterator

Is it safe or legal to call isInsideBundle even when I == E? MachineBasicBlock::iterator MachineBasicBlock::getFirstNonPHI() { instr_iterator I = instr_begin(), E = instr_end(); while (I != E && I->isPHI()) ++I; assert(!I->isInsideBundle() && "First non-phi MI cannot be inside a bundle!"); return I; } I am seeing an assert when I run llc. The code is in lib/CodeGen/MachineBasicBlock.cpp:145. ---...

...the original instruction. I had done some searching and found that eraseFromParent is used to do this so that's what I'm using in the code below: for (MachineFunction::iterator MFI = MF.begin(), E = MF.end(); MFI != E; ++MFI) { // for each instr MachineBasicBlock::instr_iterator II = MFI->instr_begin(); while( II != MFI->instr_end()) { opcode = II->getOpcode(); if(II->isCommutable() || isLoadRR(opcode)){ MachineBasicBlock& MBB = *MFI; MachineInstr& MI = *II; DebugLoc DL = MI.getDebugLoc();...

On Oct 25, 2012, at 7:01 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > Is it safe or legal to call isInsideBundle even when I == E? No, neither. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121025/cb0bdec9/attachment.html>

Please see the attached patch. There was one more line which was calling isInsideBundle without any check. On Thu, Oct 25, 2012 at 7:08 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On Oct 25, 2012, at 7:01 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > > Is it safe or legal to call isInsideBundle even when I == E? > > > No, neither. >

I just realised I forgot to reply to this. Thanks for advise, it's good to know. Thanks, Dan Liew. On 30 August 2013 16:25, David Blaikie <dblaikie at gmail.com> wrote: > On Fri, Aug 30, 2013 at 7:53 AM, Daniel Liew <daniel.liew at imperial.ac.uk> wrote: >> Hi, >> >> I'm trying to write a small piece of code that inlines all calls to a >> particular

Hi, I'm trying to write a small piece of code that inlines all calls to a particular function. The codes is as follows Function* klee_check_divF = module->getFunction("klee_div_zero_check"); assert(klee_check_divF != 0 && "Failed to find klee_div_zero_check function"); // Hack inline checks for (Module::iterator f = module->begin(), fe =

...s assert is triggered: void MachineInstr::bundleWithSucc() { assert(!isBundledWithSucc() && "MI is already bundled with its successor"); <<<<<<<<<<<<<<<<<<<<<<<< setFlag(BundledSucc); MachineBasicBlock::instr_iterator Succ = this; ++Succ; assert(!Succ->isBundledWithPred() && "Inconsistent bundle flags"); Succ->setFlag(BundledPred); } Here is the call stack: #3 ... in llvm::MachineInstr::bundleWithSucc (this=0x4c6aa20) at ...lib/CodeGen/MachineInstr.cpp:882 #4 ... in llvm::MIBun...

...new methods?... or do you have a better suggestion? Thanks. Sergei void MachineInstr::bundleWithPred() { assert(!isBundledWithPred() && "MI is already bundled with its predecessor"); <<<<<<<<<<<< setFlag(BundledPred); MachineBasicBlock::instr_iterator Pred = this; --Pred; assert(!Pred->isBundledWithSucc() && "Inconsistent bundle flags"); <<<<<<<<<<<<< Pred->setFlag(BundledSucc); } void MachineInstr::bundleWithSucc() { assert(!isBundledWithSucc() && "MI is alread...

...t; > > I need to move an instruction into this bundle from another location and > insert it _between_ AND_ri and JMP_EQriPnt_nv_V4. I use MBB->splice(...) to > do that. Let's pretend that moved instruction was not bundled. New > instruction is pointed to by MachineBasicBlock::instr_iterator MII. New > bundle right after splice is: > > v BUNDLE %R0<imp-def,dead>, %PC<imp-def>, %R18<imp-use> > *^v %R0<def> = AND_ri %R18, 128 > * %R3<def> = HexagonEXTRACTU_ri_Inst %R18, 4, 3 <<<<<<<<<<<<<<&...

On Feb 1, 2013, at 3:43 PM, "Sergei Larin" <slarin at codeaurora.org> wrote: > I have a question about the following (four) asserts recently added in > bundleWithPred() and bundleWithSucc() (see below). What is the real danger > of reasserting a connection even if it already exist? The intention was to identify code that may have been converted from the old style a

> No. An instruction on its own is equivalent to a bundle with that > instruction only. Also, a BUNDLE must have at least 2 instructions. > > -Krzysztof > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted > by The Linux Foundation > _______________________________________________ > LLVM Developers mailing list > llvm-dev at

Hello. Because I experience optimizations (DCE, OoO schedule) which mess the correct semantics of the list of instructions lowered in ISelLowering from the VSELECT LLVM instruction, and these bad transformations happen even before scheduling, at later I-sel subpasses, I try to fix this problem by lowering VSELECT to only one pseudo-instruction and LATER translate it to a list of

...ove an instruction into this bundle from another location > > and insert it _between_ AND_ri and JMP_EQriPnt_nv_V4. I use > > MBB->splice(...) to do that. Let's pretend that moved instruction was > > not bundled. New instruction is pointed to by > > MachineBasicBlock::instr_iterator MII. New bundle right after splice > is: > > > > v BUNDLE %R0<imp-def,dead>, %PC<imp-def>, %R18<imp-use> *^v > > %R0<def> = AND_ri %R18, 128 > > * %R3<def> = HexagonEXTRACTU_ri_Inst %R18, 4, 3 > <<<<<<<<&lt...