search for: instr_iterators

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

I'm writing a pass that looks at the operands of certain non-commutable instructions and swaps a couple of them if certain conditions exist (a register bank conflict in the instruction). If the conflict exists, I build a new instruction which has the 2nd and 3rd operands swapped (using BuildMI). Then I want to get rid of the original instruction. I had done some searching and found that

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 =

Jakob, > The intention was to identify code that may have been converted from > the old style a little too quickly. I wanted to avoid bugs from a > global s/setIsInsideBundle/bundleWithPred/g search and replace. This is a good intent. Maybe a bit temporal but sound nevertheless. > finalizeBundle is calling 'MIBundleBuilder Bundle(MBB, FirstMI, > LastMI)' which ought to

Jakob, 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? My problem with them happens when I try to call finalizeBundle() on an existing bundle to which I have added a new instruction. The goal - a new bundle header with liveness abbreviation, but

...ld never happen. It should always be the case that: if II->isBundledWithPred() then prior(II)->isBundledWithSucc() if II->isBundledWithSucc() then next(II)->isBundledWithPRed() In fact, the machine code verifier also checks this invariant now. I changed MBB->splice() to not accept instr_iterators so what you're doing wouldn't be possible. It is hard to add enough assertions, though. To move instructions into a bundle, I recommend that you use MIBundleBuilder with removeFromBundle(): Bundle.insert(I, MI->removeFromBundle()) This way you can insert instructions at any position...

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

...> case that: > > if II->isBundledWithPred() then prior(II)->isBundledWithSucc() if II- > >isBundledWithSucc() then next(II)->isBundledWithPRed() > > In fact, the machine code verifier also checks this invariant now. > > I changed MBB->splice() to not accept instr_iterators so what you're > doing wouldn't be possible. It is hard to add enough assertions, > though. > > To move instructions into a bundle, I recommend that you use > MIBundleBuilder with removeFromBundle(): > > Bundle.insert(I, MI->removeFromBundle()) > > This wa...