search for: finalizemachinebundles

...ic block iterator moves from bundle to bundle skipping the instructions inside the bundle. Iterating over the operands will only give us the operands of the BUNDLE instruction but that is fine, because it basically has a copy of everything inside the bundle. == When to finalize bundles; Remove the FinalizeMachineBundles pass? == However there is a number of remaining questions/confusion: The RFC indicates that the finalization step is done as a separate pass at the end of the register allocation pipeline. In fact a FinalizeMachineBundles pass exists but is not used by anyone. There is no in-tree target doing bund...

...ing over the operands > will only give us the operands of the BUNDLE instruction but that is fine, > because it basically has a copy of everything inside the bundle. The BUNDLE instruction simply isn’t necessary to do anything you just described. > == When to finalize bundles; Remove the FinalizeMachineBundles pass? == > > However there is a number of remaining questions/confusion: The RFC indicates > that the finalization step is done as a separate pass at the end of the > register allocation pipeline. In fact a FinalizeMachineBundles pass exists but > is not used by anyone. There is no...

...edges crossing the boundary. 2) Scheduler and bundler operate on the same scope (an entire block): isSchedulingBoundary = false and all instructions must be correctly handled by the DAG builder. DAG edges will be built for all instructions within the block. --- Now, regarding bundle creation. The FinalizeMachineBundles pass will "finalize" bundles for you after regalloc. You can enable that in your target config. e.g. bool MyTargetPassConfig::addFinalizeRegAlloc() { addPass(FinalizeMachineBundlesID); } This does not create bundles, rather it wraps bundles in an extra layer of abstraction by copyin...

...ink that they will pose such a big problem. I have a brief list of things that have to be done before I can move the Machine IR stuff from CodeGen to some other library: - Move the SplitCriticalEdge method from MachineBasicBlock ( http://reviews.llvm.org/D10064). - Move the UnpackMachineBundles and FinalizeMachineBundles passes from MachineInstrBundle.cpp. (http://reviews.llvm.org/D10070 + 1 upcoming patch). - Refactor SlotIndexes.h: keep the SlotIndexes pass and move the rest to SlotIndex.h. Introduce a new container class in SlotIndex.h that will extract the map between machine instructions and slot indexes fro...

...will pose such a big problem. > I have a brief list of things that have to be done before I can move the Machine IR stuff from CodeGen to some other library: > - Move the SplitCriticalEdge method from MachineBasicBlock (http://reviews.llvm.org/D10064). > - Move the UnpackMachineBundles and FinalizeMachineBundles passes from MachineInstrBundle.cpp. (http://reviews.llvm.org/D10070 + 1 upcoming patch). > - Refactor SlotIndexes.h: keep the SlotIndexes pass and move the rest to SlotIndex.h. Introduce a new container class in SlotIndex.h that will extract the map > between machine instructions and slot i...

On Thu, Mar 29, 2012 at 02:57:27PM -0500, Sergei Larin wrote: > Tom, > > I do not have your call stack, but packetizer calls > ScheduleDAGInstrs::buildSchedGraph to create dependency model. If this is > the first time you use the new MI sched infrastructure (like your target has > not implemented misched yet) there might be some work needed to implement > couple target

...ch a big problem. >> I have a brief list of things that have to be done before I can move the Machine IR stuff from CodeGen to some other library: >> - Move the SplitCriticalEdge method from MachineBasicBlock (http://reviews.llvm.org/D10064). >> - Move the UnpackMachineBundles and FinalizeMachineBundles passes from MachineInstrBundle.cpp. (http://reviews.llvm.org/D10070 + 1 upcoming patch). >> - Refactor SlotIndexes.h: keep the SlotIndexes pass and move the rest to SlotIndex.h. Introduce a new container class in SlotIndex.h that will extract the map >> between machine instructions and...

...ry. > > 2) Scheduler and bundler operate on the same scope (an entire block): isSchedulingBoundary = false and all instructions must be correctly handled by the DAG builder. DAG edges will be built for all instructions within the block. > > --- > Now, regarding bundle creation. The FinalizeMachineBundles pass will "finalize" bundles for you after regalloc. You can enable that in your target config. e.g. > > bool MyTargetPassConfig::addFinalizeRegAlloc() { > addPass(FinalizeMachineBundlesID); > } > > This does not create bundles, rather it wraps bundles in an extra...

...! I believe that we are far enough away from it that we should rather fix the status quo first to avoid all the confusion and then move forward to the header-less scheme in a targetted change. That is why I added the last paragraph in my mail. > >> == When to finalize bundles; Remove the FinalizeMachineBundles pass? == >> >> However there is a number of remaining questions/confusion: The RFC indicates >> that the finalization step is done as a separate pass at the end of the >> register allocation pipeline. In fact a FinalizeMachineBundles pass exists but >> is not used by...

Hi, Thanks for your explanations! How is the big picture for supporting in-order VLIW architectures and the like though? I am asking because I am currently implementing instruction scheduling in our own backend for our custom Patmos processor, for which I need to support both branch delay slots and bundles, some restrictions regarding bundles. For the moment, I am quite happy with a simple

On Wed, May 27, 2015 at 8:15 AM Chris Lattner <clattner at apple.com> wrote: > On May 26, 2015, at 11:20 PM, Quentin Colombet <qcolombet at apple.com> > wrote: > > +1. > > Could those two be subdirectories of one “Machine-Related-Stuff” directory? > E.g., > MachineStuff/IR > MachineStuff/CodeGen > > Where MachineStuff is something meaningful :). >