search for: bundlewithsucc

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 little too quickly. I wanted to avoid bugs from a global s/setIsInsideBundle/bundleWithPred/g search and replace....

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 because of thes...

On Feb 4, 2013, at 3:02 PM, "Sergei Larin" <slarin at codeaurora.org> wrote: > Jakob, > >> ... In this case you should either erase the old BUNDLE first, or unbundle > it >> from the instructions you are trying to finalize. > > This is exactly my point - I have to unbundle everything to re-bundle it > back in :) ...but this case is trivial and I am

...er of Code Aurora Forum, hosted by The Linux Foundation > -----Original Message----- > From: Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] > Sent: Monday, February 04, 2013 5:17 PM > To: Sergei Larin > Cc: llvmdev at cs.uiuc.edu > Subject: Re: Asserts in bundleWithPred() and bundleWithSucc() > > > On Feb 4, 2013, at 3:02 PM, "Sergei Larin" <slarin at codeaurora.org> > wrote: > > > Jakob, > > > >> ... In this case you should either erase the old BUNDLE first, or > >> unbundle > > it > >> from the instructio...

On Feb 4, 2013, at 3:44 PM, "Sergei Larin" <slarin at codeaurora.org> wrote: > Seems like an easy solution for this case... But let me ask you a more > general question. > The reason I kept on hanging on to the MBB->splice was (probably outdated) > assumption that it will one day properly update liveness for instructions it > moves... That is a serious matter

...r of Code Aurora Forum, hosted by The Linux Foundation > -----Original Message----- > From: Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] > Sent: Monday, February 04, 2013 11:53 AM > To: Sergei Larin > Cc: llvmdev at cs.uiuc.edu > Subject: Re: Asserts in bundleWithPred() and bundleWithSucc() > > > On Feb 4, 2013, at 8:59 AM, "Sergei Larin" <slarin at codeaurora.org> > wrote: > > > Jakob, > > > >> The intention was to identify code that may have been converted from > >> the old style a little too quickly. I wanted to avoi...

...;imp-use> (next bundle). finalizeBundle() is called with: FirstMI == STrid_indexed %R29, 80, %D8<kill>; mem:ST8[FixedStack2] LastMI == BUNDLE %R29<imp-use>, %D10<imp-use,kill>, %R7<imp-use>, %D6<imp-use> >From here this 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->...

...er of Code Aurora Forum, hosted by The Linux Foundation > -----Original Message----- > From: Jakob Stoklund Olesen [mailto:stoklund at 2pi.dk] > Sent: Monday, February 04, 2013 6:09 PM > To: Sergei Larin > Cc: llvmdev at cs.uiuc.edu > Subject: Re: Asserts in bundleWithPred() and bundleWithSucc() > > > On Feb 4, 2013, at 3:44 PM, "Sergei Larin" <slarin at codeaurora.org> > wrote: > > > Seems like an easy solution for this case... But let me ask you a > > more general question. > > The reason I kept on hanging on to the MBB->splice wa...

On Feb 4, 2013, at 8:59 AM, "Sergei Larin" <slarin at codeaurora.org> wrote: > 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