search for: finalizebundl

...ent > couple target hooks. isSchedulingBoundary is one of them. Also try to > disable that assert and see what happens. It sounds strange, but in some > cases that assert is overly restrictive. Thanks, I disabled that assert, and I got a little farther. I hit some more assertion failures finalizeBundle, because the instructions were still using virtual registers. I'm not sure why finalizeBundle doesn't currently handle virtual registers, maybe the implementation isn't complete yet? If I remove those asserts in finalizeBundle, I can get the program to compile, and it has the VLIW bu...

...g 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. > 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 these asserts I now have to unbundle all, and > re-bundle them right back again for no obvious benefit... finalizeBundle is calling 'MIBundle...

...hooks. isSchedulingBoundary is one of them. Also try to >> disable that assert and see what happens. It sounds strange, but in some >> cases that assert is overly restrictive. > > Thanks, I disabled that assert, and I got a little farther. I hit > some more assertion failures finalizeBundle, because the > instructions were still using virtual registers. I'm not sure why > finalizeBundle doesn't currently handle virtual registers, maybe the > implementation isn't complete yet? > > If I remove those asserts in finalizeBundle, I can get the program > to c...

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 these asserts I now have to unbundle all, and re-bundle them right back again for no obvious benefit... In other words, may I suggest removing them rather th...

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

...ry is one of them. Also try to > >> disable that assert and see what happens. It sounds strange, but in some > >> cases that assert is overly restrictive. > > > > Thanks, I disabled that assert, and I got a little farther. I hit > > some more assertion failures finalizeBundle, because the > > instructions were still using virtual registers. I'm not sure why > > finalizeBundle doesn't currently handle virtual registers, maybe the > > implementation isn't complete yet? > > > > If I remove those asserts in finalizeBundle, I can...

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

Sergei, Thank you for your attention. My target is a custom VLIW DSP. I am not sure dependency dag is correct when it gets scheduled and packetized. Months ago, I submitted a bug at http://llvm.org/bugs/show_bug.cgi?id=17894 which explained more details. I am not sure my understanding of this bug is proper, but modified my local codes this way and it works for my target when scheduling and

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 hooks. isSchedulingBoundary is one of them. Also try to disable that assert and see what happens. It

On Thu, Mar 29, 2012 at 01:50:58PM -0500, Sergei Larin wrote: > Tom, > > What is in your isSchedulingBoundary? If it contains isLabel you might > need to disable that assert: > > assert(!MI->isTerminator() && !MI->isLabel() && > "Cannot schedule terminators or labels!"); > > Sergei Larin > > -- > Qualcomm

...invoked before the "Eliminate PHI nodes for register allocation" pass. If however, there is a simple possibility to bundle MachineInstr before RA, please let me know. Thank you, Alex PS: Is there a possibility to bundle MachineInstr instructions before RA and use llvm::finalizeBundle() on these bundles in a pass invoked after RA?

...cket - End the current packet, bundle packet instructions and reset // DFA state. void VLIWPacketizerList::endPacket(MachineBasicBlock *MBB, MachineInstr *MI) { if (CurrentPacketMIs.size() > 1) { MachineInstr *MIFirst = CurrentPacketMIs.front(); finalizeBundle(*MBB, MIFirst, MI); } CurrentPacketMIs.clear(); ResourceTracker->clearResources(); } Based on this, it looks like packets with one instruction are not finalized (finalizeBundle is the one which inserts a BUNDLE instruction). So what happens with packets that have only 1 instruction? Is t...

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

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

...Using the pass today does not even work as the MachineVerifier will reject the > intermediate unfinalized state (missing internal read markers). I'd suggest to get > rid of the pass and the idea of delegating finalization to an own pass, any objections? No objections. Also, the existing finalizeBundle function works on Hexagon mostly by luck. Hexagon's packet semantics is "mostly" parallel. In general all registers are read before any register updates take place. The current function works by scanning the bundle sequentially. That doesn't cause problems for us, mostly beca...

...cket - End the current packet, bundle packet instructions and reset // DFA state. void VLIWPacketizerList::endPacket(MachineBasicBlock *MBB, MachineInstr *MI) { if (CurrentPacketMIs.size() > 1) { MachineInstr *MIFirst = CurrentPacketMIs.front(); finalizeBundle(*MBB, MIFirst, MI); } CurrentPacketMIs.clear(); ResourceTracker->clearResources(); } My initial idea was to simply add a NOP instruction to the CurrentPacketMIs, but it is proving to be more difficult than I thought. Would anyone care to help? -- Rail Shafigulin Software Engineer Esenc...

I am using machine instruction bundles [1] before register allocation. This appears not to be too common today and I'd really like some input on the intentions and plans of the current system. And would like some input on clean up proposals. [1] I am currently experimenting to use machine instruction bundles to reliably form macroop fusion opportunities without spills, reloads, splits or

...nds 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. That may all be true. However I'd like to point out that this is the status quo! finalizeBundle() will give you the BUNDLE instruction in the header and it is used by everyone using bundles: ARM, and AMDGPU target and the DFAPacketizer (which is used by Hexagon). Not using BUNDLE and correctly using MIBundleOperands at the right places in the register allocator is not where the code is toda...

...ruction 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. > > That may all be true. However I'd like to point out that this is the status quo! finalizeBundle() will give you the BUNDLE instruction in the header and it is used by everyone using bundles: ARM, and AMDGPU target and the DFAPacketizer (which is used by Hexagon). > > Not using BUNDLE and correctly using MIBundleOperands at the right places in the register allocator is not where the co...

...day does not even work as the MachineVerifier will reject the >> intermediate unfinalized state (missing internal read markers). I'd suggest to get >> rid of the pass and the idea of delegating finalization to an own pass, any objections? > > No objections. Also, the existing finalizeBundle function works on Hexagon mostly by luck. Hexagon's packet semantics is "mostly" parallel. In general all registers are read before any register updates take place. The current function works by scanning the bundle sequentially. That doesn't cause problems for us, mostly because...