search for: bundlewithpreds

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

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

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

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

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

Hi, I am looking at the Hexagon MI Scheduling and trying to adapt it to my target. As far as I can see, Hexagon does not bundle the VLIW-bundles by calling bundleWithPred() on MIs of the completed cycle. First of all, why is this not done? SlotIndexes seems to have at least some support for this, by calling getBundleStart() for each MI that is looked up. A follow up question is then, how would

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 OK with it. What is more unclear to me is this. How do you use Bundle.insert(I, MI->removeFromBundle()) Where MI == Bundle.End?

Jakob, 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 for what I am trying to do (global code motion in presence of bundles). What is the current thinking? Will

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

Jakob, Consider a counterexample. In a late pass I speculatively move instructions between BBs to improve code density and handle some peculiar back end specific situations which could not be handled in earlier passes. I move instructions one at a time. Currently I do it in a worklist fashion - I collect several possible candidates, and then actually move one. Some moves are _speculative_. Next

Hi all, I have faced a little bit of a strange transformation from the TailDuplicatePass In CodeGen. When the pass clones the contents of TailBB into PredBB, the bundled instructions in TailBB are not bundled in PredBB. I think the reason why it is not bundled is that the 'DuplicateInstruction' function does not set up the flag of the first instruction of the bundle in PredBB when it