search for: firstmi

...undle to which I > have added a new instruction. The goal - a new bundle header with liveness > abbreviation, but because of these asserts I now have to unbundle all, and > re-bundle them right back again for no obvious benefit... finalizeBundle is calling 'MIBundleBuilder Bundle(MBB, FirstMI, LastMI)' which ought to work with pre-bundled instructions. FirstMI and LastMI must be pointing at bundle boundaries, but you shouldn't need to unbundle everything. Which iterators are you passing to finalizeBundle? /jakob

...ave 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 work with pre-bundled instructions. Not exactly. Let me illustrate couple cases here (for illustration purposes "^" means "isBundledWithPred()" and "v" means "isBundledWithSucc()"): I have the following (existing) bundle f...

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

...t;> 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 work with pre-bundled instructions. > > Not exactly. Let me illustrate couple cases here (for illustration purposes > "^" means "isBundledWithPred()" and "v" means "isBundledWithSucc()"): > > I have the...

...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 work with pre-bundled instructions. > > > > Not exactly. Let me illustrate couple cases here (for illustration > > purposes "^" means "isBundledWithPred()" and "v" means > "isBundledWithSucc()")...